On Nov 12, 2014, at 5:12 AM, Victor Sergeyev <vserge...@mirantis.com> 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 <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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to