Excerpts from Mike Bayer's message of 2015-05-16 19:45:47 -0400: > > On 5/16/15 10:05 AM, Doug Hellmann wrote: > > Excerpts from Mike Bayer's message of 2015-05-15 13:13:39 -0400: > >> On 5/15/15 9:31 AM, Doug Hellmann wrote: > >>> 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. > >> Then we have a forever-in-perpetuity dependency on SQLAlchemy-Migrate > >> which must be maintained forever for to maintain compatibility with all > >> new SQLAlchemy, oslo.db, etc. releases, despite it never being used for > >> anythine new, because it will be impossible to install an Openstack > >> application without running through the first set of migrate scripts first. > > The oslo.db team is also doing work to make it possible to initialize a > > database without running the migrations. We might need one or two to > > insert some data, but I thought we were trying to ensure that was done > > with commands rather than migration scripts. If not, we should be able > > to reduce the number of migrations we eventually have to port. > > > >> The SQLAlchemy-Migrate dependency must be dropped and the project has to > >> be EOL'ed at some point. Leaving it in is definitely the more > >> complicated alternative. > > Yeah, I wasn't proposing that we keep it forever. > > This doesn't answer the key question. An application is deployed at > Juno, it has a sqlalchemy_migrate table and its on Migrate version > "X". The Liberty version of the code does not use Migrate. How to > upgrade from Juno to Liberty? Kilo migration is required?
Do we support skipping versions now? > I really would prefer porting of sqlalchemy-migrate files as an option, > because I can do this for projects very easily. The calling styles are > not very different and Alembic's is also a lot more succinct as you > don't have to spell out a whole Table to add a column or constraint. > Also, as an upstream project Alembic deserves to have a clean upgrade > path for projects that want to port from sqlalchemy-migrate to alembic, > so this is work that is worth doing in any case. OK, I'm not saying *don't* do that, just that in the past we have resisted the idea of changing migration scripts and so we were looking for a path that didn't require touching all of them. If there is consensus that it's OK to re-create the migrations using alembic, then I think it's fine to do that. 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
