database wrapper ?

Mike Orr sluggoster at gmail.com
Thu Feb 5 16:37:48 EST 2009


On Feb 1, 3:47 pm, Stephen Hansen <apt.shan... at gmail.com> wrote:
> Googling, I found SQLalchemy,
> which looks quit good.
> SQLAlchemy is very good. I'm very slowly migrating our entire codebase to it.
>  
>
>
> But as I only want to choose once,
> I googled for  "SQLalchemy alternatives",
> but it didn't find many answers.
> (Storm / Grok are of no interest, because manipulating the structure of the database is a key issue).
> There's a few other alternatives-- if you google "Python ORM" you'll find a lot more, and PyPi might have a list. But IMHO, SQLAlchemy is the best of breed so far. Its very, very flexible and doesn't really impose on you with any rules about how you must do things.
> Storm's not bad, don't get me wrong!
> But one question on your requirements: manipulating the structure of the database. How so? If you mean that you want to be able to modify the object wrapper to change some field of a table and have that change propagated to the database layer... then SQLAlchemy doesn't support that. If you add new tables it'll create them, and it MIGHT add new columns or indexes if you add them after and it notices they aren't there... but I'm not entirely sure on that.

engine.execute("ALTER TABLE ...")

However, this may confuse ORM objects already in memory as well as
transactions, so clear these out both before and afterward.  The
syntax is database specific.  MySQL can add and delete columns and
change a column's type.  SQLite can only rename tables.  However, your
ORM objects won't know about the new columns unless you reinitialize
the Table objects and mapper with autoloading.  So it's best to modify
the schema in a standalone program that does not use the ORM.

As for modifying the columns in the Table objects and propagating the
changes to the database, you can't do that.  You have to execute
"ALTER TABLE" as a string command.  SQLAlchemy would have to add a
whole new layer to deal with alternations at the Table or SQL builder
level, and in the end they're still database specific.





More information about the Python-list mailing list