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?
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.
__________________________________________________________________________
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
__________________________________________________________________________
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
