On Fri, May 15, 2015 at 11:54 AM, Mike Bayer <[email protected]> wrote:
> > > On 5/14/15 7:12 PM, Angus Salkeld wrote: > > > > On Fri, May 15, 2015 at 4:46 AM, Mike Bayer <[email protected]> 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. > Thanks. Would you suggest we hold off moving to alembic (in Heat) until you have this ironed out? I just want to make sure we don't do this prematurely. -Angus > > > > > -Angus > > >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
