-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Bayer ha scritto: > 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.
Another solution is to add a completely new interface. The engine will have new `upgrade` and `downgrade` methods, and SQLAlchemy will have a new engine.migrate module, with custom Visitors for migration events. You can migrate a MetaData or single Tables. > 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. The idea was to use functions, and not scripts. I would add the migration functions in the same module where the metadata is defined. I don't see problems with this. Only a single function is called at one time. > Similarly, the concept of a "version" as an integer number is not really > flexible enough - The idea was to keep it simple. > I would like to investigate the creation of migration > scripts between branches as well. The version can then be a string, but it needs to sortable (see setuptool as an example). > The mechanism of schema versioning is > not at all something that belongs in SQLAlchemy core. > Yes. But it is a simple metadata. It can also be stored in the `info` dictionary (and this is what I plan to do if I have to write the support by myself). > 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. > +1 > 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. > Another problem, for me, is that migration scripts apply to the whole database (unless I'm missing something - I have only read the documentation and some of the code). However in my projects I have several metadata objects. Some of these metadata objects are defined in external packages. This is the reason why I think that migration should be implemented as normal callback functions. And it should possible to register several event listeners on the same event, so that an application can add its own behaviour when a schema in an external package is upgraded/downgraded. > [...] Manlio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuP854ACgkQscQJ24LbaUTmiACePF2aKGBYbWgVLle5B5aHuqdV HNkAoJe2czsAXtTF1AFAvyUvMs/qJ+2z =bNMq -----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.
