[openstack-dev] [oslo][all] Alembic migrations for SQLite

Doug Hellmann doug at doughellmann.com
Tue Nov 11 15:58:47 UTC 2014


On Nov 10, 2014, at 10:55 AM, Mike Bayer <mbayer at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list