Justin Johnson wrote:
> Lastly, it would be great if there could be some collaboration on a
> combined administration/migration tool, similar in scope to
> sqlobject-admin. ORM-specific administration isn't really very useful
> -- especially when you can't be sure the ORM describes anything similar
> to what some legacy database looks like (before the upgrade). And the
> kinds of functions you want to upgrade a database (ALTERs and table
> introspection, etc) are relatively uncommon in everyday database use, so
> including them in an ORM is unnecessary scope creep. I think a
> cross-ORM tool (and just as applicable to no ORM) would be an easy place
> for collaboration.
I was hoping to get around to implementing a migration system similar to
RoR's migration system. It's being used to good effect in production
environments.
It's not perfect but it's at least an attempt to provide a managable
framework for upgrades (and downgrading if necessary). It essentially
works by having up() and down() methods in a Migrator class which
contain functionality to upgrade/downgrade respectively. It's not
automated - the methods contain the necessary calls to create/remove
fields and populate data etc if they need to.
Please don't copy the class structure Rails people uses... I find it
ugly similar to the way Java ported to Python is ugly. ActionMailer is
a study in insane framework construction, and it sounds like their
migration stuff might be going down the same kind of path. But
certainly learning from others' successes and failures is always good.
I agree that automation is too hard to be useful; better to provide
tools to manage the versions and hand-written upgrade scripts, and tools
to help developers write those upgrade scripts. Just dumping out SQL
and doing a diff is a pretty good start, for instance. And some
functions that make updates and alters easy to express
But, unless I'm mistaken, currently SQLObject doesn't abstract dropping
of indices and a few other necessary methods supporting full table alter
abilities.
I think it's easier to keep SQLObject and table modification somewhat
separate. An upgrade script should be tied to two *database* versions,
and not to any particular state of the actual code (which may have been
updated even further, with more upgrade scripts to be applied in the
future).
And thought SQLObject does support alter statements, of course that
makes the result SQLObject-specific. Though if it's a hand-written
script (with a generic management structure) then it's okay to use
whatever tools are natural. I'd be happy enough if I could put magic
methods on *Col objects and the like, and have the management tool
understand them that way.
Will at least enough functionality to add/remove columns and indexes be
present in the sqlapi layer? I'd suggest that it's needed so that we
can write tools that sit on top of SQLObject without having to write an
independant database abstraction library (repeating a lot of code no
doubt).
SQL-API is intended to replace/augment/extract SQLObject's database
abstraction. SQLObject2 doesn't have any database-specific stuff in it,
it uses SQL-API as an intermediary. Some things can't be transparently
abstracted -- for instance, the difference between databases that use
AUTO_INCREMENT, and those that use sequences. But SQL-API at least
exposes that distinction in a documented way. (The document is just an
interface, but I've been keeping it up to date:
http://svn.sqlobject.org/sqlapi/trunk/sqlapi/interfaces.py -- some of it
really plays to an abstract superclass, though:
http://svn.sqlobject.org/sqlapi/trunk/sqlapi/backend/generic.py)
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
