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.
