Great job, Mike, thanks! Doug, as for migration from sqlalchemy-migrate to Alembic - at the moment it's hard to realize this because we suppose to keep backward compatibility with available migrations. I'd like to re-review existing approach with Mike and Roman, create road-map for this migration, and try to migrate one of the projects as Proof-Of-Concept.
On Tue, Nov 11, 2014 at 5:58 PM, Doug Hellmann <d...@doughellmann.com> wrote: > > On Nov 10, 2014, at 10:55 AM, Mike Bayer <mba...@redhat.com> wrote: > > > Bonjour openstackers - > > > > While you were all sipping champagne on the Champs-Élysées, I took some > time to tackle one of the two most critically wanted features in Alembic, > which is that of being able to migrate tables on a SQLite database with > some degree of sanity. My immediate focus on Alembic was spurred on > partially because some changes to the test suite pushed it into 0.7.0, and > then we got a very large number of bug fixes in, so the urgency to get > 0.7.0 is relatively high; but what good is a pseudo-major point release > without some big new features ? > > > > The feature works similarly to that of SQLAlchemy-Migrate, but I’m > hoping in a way that is more controllable and open-ended. I would > encourage all those interested to take a look at the basic mode of > operation over at > http://alembic.readthedocs.org/en/latest/tutorial.html#running-batch-migrations-for-sqlite-and-other-databases. > Highlights include that several table operations can take place within one > “move and copy” operation at once, and the system can also be applied to > other databases if one so desired (not a common use case but some have > expressed interest in this being possible…so it is!). The format of a > SQLite-compatible migration script will change slightly, though for the > better as per-table operations are grouped together, and the scripts of > course in the default case continue to work exactly as before on all other > target databases. > > This sounds great, Mike, and I’m sure it will make it much easier for us > to use sqlite databases for unit/functional tests. > > > > > I know that a handful of projects have moved or started with Alembic, > and I’d like to continue pushing Alembic to be the single solution across > all projects. There’s some work in oslo.db to define a common > environmental format as well (see https://review.openstack.org/#/c/112842/). > I would encourage projects to continue to evaluate moving their migrations > over to Alembic at some point in the future, which should also include > sending me emails/ircs/bug reports about what additional features/fixes are > needed. > > I want to stress this. We ran into issues with sqlalchemy-migrate during > Juno, and we’re having an increasingly difficult time finding reviewers > even though OpenStack (not Oslo) has adopted the library. The Oslo team is > working on improving Alembic support with the intent to deprecate support > for sqlalchemy-migrate in the “near future” (not Kilo). Please work with > Mike, Viktor, Roman, and the rest of the oslo.db team to identify any holes > that would delay your ability to start using alembic for new migrations in > the next release cycle. > > > > > The next major feature for Alembic, which I will tentatively use this > week to see if I can get it online, is the multiple heads/branch resolution > feature ( > https://bitbucket.org/zzzeek/alembic/issue/167/multiple-heads-branch-resolution-support) > which a *lot* of people are really asking for. This feature would allow > independent migration series to coexist simultaneously, as well “merge > point” migrations that join disparate branches back into a single stream. > The risk level for this feature is significantly higher than that of the > SQLite migration feature, as while the SQLite migration feature lives > entirely within a new API that is otherwise unused, the multiple branch > feature makes some fundamental changes to how versioning is performed. So > while I’d like to get this in 0.7.0 as well, if it gets into the weeds I > may have to push 0.7.0 without it as there’s really a crapload of other > fixes to be pushed. > > > > Thanks for reading! > > > > - mike > > > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev