Open Stack

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 <doug at doughellmann.com>
wrote:

>
> 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141112/1555bf53/attachment.html>