I'm pretty much -1 on this since I think migrations need to have absolute flexibility - the "listener" system within create_all() is not at all designed to be used to that degree. For starters, its an entirely in-memory system - if you have hundreds of migration scripts its quite cumbersome to read them all into memory for a single migration. Similarly, the concept of a "version" as an integer number is not really flexible enough - I would like to investigate the creation of migration scripts between branches as well. The mechanism of schema versioning is not at all something that belongs in SQLAlchemy core.
I would like to implement an "alternate" version of Migrate at some point as an example or recipe - the ALTER constructs themselves could eventually live within SQLAlchemy.schema, since those are non-controversial atomic units of functionality. The "versioning" would be a simple script system that starts with the "integer" version but could later work off of md5 hashes perhaps - but this would just be a usage recipe, that like the PostGIS example would launch into a real product. the main point would be that the scripting system would be cleanly separated from the system of interaction with the database. The existing Migrate project is burdened by three things - the monkeypatching legacy of older SQLA versions, an overly rigid and complex system of creating "engines" that makes it almost impossible to control the transactional scope of a migration, and its superfluous features, namely the whole "schema comparison" system that I could do without. Manlio Perillo wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi. > > I would like to implement a minimal but working support to migrations in > SQLAlchemy. > > I know there is already sqlalchemy-migration, but the code is not > integrated in SQLAlchemy, and it is less flexible. > > A detailed description of the propose is here: > http://mperillo.ath.cx/migration.html > > Please let me know if it is ok to integrate this in SQLAlchemy, and, of > course, if there are bugs in the propose. > > If all is ok, I will start to write a patch; otherwise I will try to > implement it as a normal SQLAlchemy extension. > > > > Thanks Manlio > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkuP2tQACgkQscQJ24LbaUTvqwCdGCln+NE8boAUS4j7PUCGXpHe > IxMAn2aMp/c8P+3BXaKS4lpFat/4Ktb3 > =ZJPs > -----END PGP SIGNATURE----- > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalch...@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
