Open Stack

Excerpts from Mike Bayer's message of 2015-05-14 21:54:27 -0400:
> 
> On 5/14/15 7:12 PM, Angus Salkeld wrote:
> >
> >
> > On Fri, May 15, 2015 at 4:46 AM, Mike Bayer <mbayer at redhat.com 
> > <mailto:mbayer at redhat.com>> wrote:
> >
> >
> >
> >     On 5/14/15 11:58 AM, Doug Hellmann wrote:
> >
> >
> >         At one point we were exploring having both sqlalchemy-migrate and
> >         alembic run, one after the other, so that we only need to
> >         create new
> >         migrations with alembic and do not need to change any of the
> >         existing
> >         migrations. Was that idea dropped?
> >
> >
> >     to my knowledge the idea wasn't dropped.   If a project wants to
> >     implement that using the oslo.db system, that is fine, however
> >     from my POV I'd prefer to just port the SQLA-migrate files over
> >     and drop the migrate dependency altogether.  Whether or not a
> >     project does the "run both" step as an interim step doesn't affect
> >     that effort very much.
> >
> >
> > Hi Mike
> >
> > Just a quick question: How would the alembic scripts know where to 
> > start the migration from if the current installation had been up until 
> > that
> > point been using migrate (I believe both alembic and migrate write to 
> > a small table what the current version is, would you look for that?)?
> Thinking about that issue, the most controllable and clean-break way to 
> do it would be to add support to Alembic itself that augments its own 
> handling of the "alembic_version" table to transfer data from an 
> existing sqlalchemy_migrate table.  I can even see using traditional 
> alembic hex-style version numbers in migration files which then also can 
> refer to their previous numerically-based migrate file.
> 
> It's not unreasonable that Alembic would support some standard upgrade 
> path from Migrate, the only other migration tool SQLAlchemy has ever 
> had, so I'd just add that as a feature.

This seems more complicated than needed. If we just stop writing the
sqlalchemy-migrate scripts and don't change them, then for 1 cycle we
have to run both sets of migrations and after that we can just run
alembic.

Doug