-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.
