[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