openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #10737
Re: database migration cleanup
Even better, what would it take to try using Alembic? (http://alembic.readthedocs.org/en/latest/front.html#project-homepage)
It's a big improvement over sqlalchemy. Amongst other things, migrations are not numbered, they are linked by dependancy, and run in topological-sort order. That there eliminates alot of "my migration number got taken... again..." problems.
On Apr 27, 2012, at 10:47 AM, Dan Prince wrote:
>
>
> ----- Original Message -----
>> From: "Sean Dague" <sdague@xxxxxxxxxxxxxxxxxx>
>> To: openstack@xxxxxxxxxxxxxxxxxxx
>> Sent: Friday, April 27, 2012 10:21:17 AM
>> Subject: Re: [Openstack] database migration cleanup
>>
>> On 04/26/2012 03:24 PM, Dan Prince wrote:
>> <snip>
>>> I think this scheme would support users who follow stable releases
>>> as well as users who follow trunk very closely.
>>>
>>> We talked about this at the conference but I thought this issue
>>> might be near and dear to some of our end users so it was worth
>>> discussing on the list.
>>>
>>> What are general thoughts on this approach?
>>
>> Is there any support in sqlalchemy, or related tools, to handle
>> migrations the way rails does, where a schema file is created at the
>> end
>> of every migration? It would be ideal if we both had a full migration
>> history, as well as a short cut at any snap shot to get to the end.
>
> Ah. Yes, the Rails schema.rb. I looked around for just this sort of thing and didn't find much. Python-migrate has some "experimental" support for generating models and I did make use of that initially. See 'create_model' below:
>
>
> [root@nova1 migrate_repo]# python ./manage.py --repository=./ --url=mysql://nova:password@localhost/nova
> Usage: manage.py COMMAND ...
>
> Available commands:
> compare_model_to_db - compare MetaData against the current database state
> create - create an empty repository at the specified path
> create_model - dump the current database as a Python model to stdout
> db_version - show the current version of the repository under version control
> downgrade - downgrade a database to an earlier version
> drop_version_control - removes version control from a database
> help - displays help on a given command
> make_update_script_for_model - create a script changing the old MetaData to the new (current) MetaData
> manage - creates a Python script that runs Migrate with a set of default values
> script - create an empty change Python script
> script_sql - create empty change SQL scripts for given database
> source - display the Python code for a particular version in this repository
> test - performs the upgrade and downgrade command on the given database
> update_db_from_model - modify the database to match the structure of the current MetaData
> upgrade - upgrade a database to a later version
> version - display the latest version available in a repository
> version_control - mark a database as under this repository's version control
>
> ----
>
> python-migrate's 'create_model' does not however give you something that exactly matches the schema you'd get by running the all the migrations. So auto generation doesn't appear to be an option right now. It would be nice to contribute python-migrate in this regard and get better support for model generation, etc. Maybe a good long term goal?
>
> Dan
>
>
>>
>> -Sean
>>
>> --
>> Sean Dague
>> IBM Linux Technology Center
>> email: sldague@xxxxxxxxxx
>> alt-email: sdague@xxxxxxxxxxxxxxxxxx
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
--
Monsyne M. Dragon
OpenStack/Nova
cell 210-441-0965
work x 5014190
Follow ups
References