<div dir="ltr">Great job, Mike, thanks!<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 11, 2014 at 5:58 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Nov 10, 2014, at 10:55 AM, Mike Bayer <<a href="mailto:mbayer@redhat.com">mbayer@redhat.com</a>> wrote:<br>
<br>
> Bonjour openstackers -<br>
><br>
> 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 ?<br>
><br>
> 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 <a href="http://alembic.readthedocs.org/en/latest/tutorial.html#running-batch-migrations-for-sqlite-and-other-databases" target="_blank">http://alembic.readthedocs.org/en/latest/tutorial.html#running-batch-migrations-for-sqlite-and-other-databases</a>.   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.<br>
<br>
</span>This sounds great, Mike, and I’m sure it will make it much easier for us to use sqlite databases for unit/functional tests.<br>
<span class=""><br>
><br>
> 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 <a href="https://review.openstack.org/#/c/112842/" target="_blank">https://review.openstack.org/#/c/112842/</a>).  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.<br>
<br>
</span>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.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> 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 (<a href="https://bitbucket.org/zzzeek/alembic/issue/167/multiple-heads-branch-resolution-support" target="_blank">https://bitbucket.org/zzzeek/alembic/issue/167/multiple-heads-branch-resolution-support</a>) 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.<br>
><br>
> Thanks for reading!<br>
><br>
> - mike<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>