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 <mba...@redhat.com > > <mailto:mba...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev