south currently uses state freezing (which aways felt messy), but i believe the new rewrite for inclusion in django core is moving to a way of describing schema changes in a declarative way that can be introspected (so current state is calculated from all previous migrations instead of some frozen state)
this also allows large chunks of historic migrations to be squashed into new "shortcut" migrations which sounds nice i'm not familiar with alembic (nor south) internals, but this sounds like an interesting idea. is it something you have considered? -david On Friday, 19 July 2013 23:00:21 UTC+1, Michael Bayer wrote: > > Hey gang - > > Alembic 0.6.0 has been sitting in the hopper for awhile so I figured I'd > put it out. The two changes here I'm most excited about are no longer > needing 2to3 for Python 3, and also I've made the display of "history" much > nicer, since I used that a lot and I needed something easier to read - it > also allows for ranges now too. > > There's some other nifty changes that have more potential than they might > initially seem to, including that you can now add any number of custom > arguments to any command using the new "-x" option, and then parsing for > them in your env.py using get_x_argument(), and there's also a new feature > that allows you to limit autogenerate at the column level, in addition to > the table and schema level as before. > > There's a bunch of issues that have piled up in Alembic, the vast majorty > concern autogenerate, and there's another thread that refers to how > Alembic's versioning model works. There are some "big" ideas in place to > rework both of these systems in a fairly dramatic way. > > For autogenerate, the idea is that we would in most cases not rely upon > database reflection anymore, instead we will try to compare schemas based > on different versions of the code directly. This would require that the > current state of the incoming MetaData() is written out to some serialized > format, which I'm thinking might be nice as JSON - though it can start as > pickle. Creating a MetaData->JSON serializer/deserializer would be great > but also a very big job. The advantage to comparing Python-generated > metadata objects is that we are guaranteed to catch all changes in the > schema perfectly, defaults, types, arguments on types, all of it, without > any reliance on the quirks of database reflection - since the purpose of > autogenerate is really just to detect what Tables/Columns have been added, > removed or changed in the code, versus what the code was before. > Decisions have to be made here as to what role reflection will continue to > play, what the upgrade path will be for existing deployments, does the > behavior kick in automatically or does it require some configuration, etc. > > > The other change to the versioning model is just as dramatic and involves > reworking the versioning to work based on an open-ended dependency graph, > meaning any particular revision is dependent on zero or more previous > revisions, rather than all revisions being lined up in a straight line. > The upgrade process would then find itself at a certain target by > navigating the topological sort of this dependency graph, pretty much the > same idea as how SQLAlchemy's unit of work functions. With this model, > the issue of merging branches mostly goes away, as two unrelated migrations > from different branches can both be pulled in and just be siblings of each > other without issue. > > Neither of these two changes are something I personally need in any urgent > way - I generally treat database migrations as a mostly manual process in > any case and I'm happy to edit the mistakes in my autogenerate migrations > by hand and to deal with the very occasional merge manually. I do get a > lot of complaints about the many edge cases present in autogenerate at > least so at some point it would be nice to get to this issue. > > Anyway, 0.6.0 is ready to go, happy downloading: > > https://pypi.python.org/pypi/alembic > > https://alembic.readthedocs.org/en/latest/changelog.html#change-0.6.0 > > > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
