[Grok-dev] simple (advanced) tuturial for grok+workflow engine+sqlalchemy?

Martijn Faassen faassen at startifact.com
Tue Dec 16 09:31:25 EST 2008


Peter Bengtsson wrote:
> I've never used it myself but I hear that Storm is a pretty good
> alternative to SqlAlchemy. The key difference is that SqlAlchemy
> assumes that it can set up the tables whereas Storm leeches on an
> existing of tables and stuff. 

That's not quite true; that's somewhat muddled Storm propaganda. :)

The truth is that SQLAlchemy can set up the tables itself *or* reflect 
them from the database (megrok.rdb supports both use cases. I have 
projects with each use cas). Storm can only use existing tables.

Some Storm people argue that this is the Only True Way to do it as 
database admins want control over the schema and don't tolerate Python 
programs generating schemas, and that this is the only scalable way to 
do relational databases. I think we want to support both scenarios; 
something like Django may very well annoy db admins and not be scalable 
to huge databases, but it's still popular and useful!

That's not to say Storm is a bad ORM system; far from it. But SQLAlchemy 
can definitely do both.

[snip]
> Django "solves" this problem by a script that inspects a legacy
> database structure and generates the python code (called "models"). I
> don't know if there is such a feature in either SqlAlchemy or Storm.

I dont know the details about Storm, but SQLAlchemy can do this dynamically.

With megrok.rdb, it looks like this:

from megrok import rdb

class Customer(rdb.Model):
     rdb.reflected()

This will reflect a table called 'customer' from the database.

I weighed Storm versus SQLAlchemy for quite a bit when trying to figure 
out which ORM system to use for megrok.rdb. I haven't regretted the 
choice for SQLAlchemy. Besides it being an extremely capable system I've 
also received excellent support from its developers.

Regards,

Martijn



More information about the Grok-dev mailing list