On Nov 12, 2014, at 5:12 AM, Victor Sergeyev <[email protected]> wrote:
> 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. The plan we came up with before was to stop adding new sqlalchemy-migrate migrations and start adding new ones with Alembic. We would then run both tools (sqlalchemy-migrate followed by alembic) to apply all migrations. When the older migrations can be deprecated, we can drop the sqlalchemy-migrate step. I thought we were still on track to follow that plan. Have you identified an issue that would prevent us from starting the cut-over to writing alembic migrations for L or M? Doug > > On Tue, Nov 11, 2014 at 5:58 PM, Doug Hellmann <[email protected]> wrote: > > On Nov 10, 2014, at 10:55 AM, Mike Bayer <[email protected]> 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 > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
