openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #01398
Re: GLANCE: How to deal with SQLAlchemy-migrate problems
On Mon, Mar 21, 2011 at 3:27 PM, Brian Schott <bfschott@xxxxxxxxx> wrote:
> I've done a few migration scripts in recent weeks for our nova/hpc-trunk. It was a painful learning curve mostly because I come from the Perl generation, but I got through it.
>
> Is the design pattern for migrations written down somewhere? If not, we should add some instructions to the migrate_repo/README file.
>
> The transition from austin/bexar.py files where all transforms are in a lump to individual files. This does have grief This is a good change, but the template example I used didn't have a downgrade function.
>
> bschott@island100:~/source/nova/nova-trunk/nova/db/sqlalchemy/migrate_repo/versions$ grep downgrade *.py
> 001_austin.py:def downgrade(migrate_engine):
> 008_add_instance_types.py:def downgrade(migrate_engine):
> 010_add_os_type_to_instances.py:def downgrade(migrate_engine):
>
> My only suggestion to Jay is that it is perfectly acceptable to do a migration in multiple stages. Less efficient, but it might traverse less untested code in SA-migrate.
Hi Brian,
1) Did you do unit tests on your migration scripts? Did you use
SQLite, MySQL and PostgreSQL?
2) Did you use SQL scripts, not Python change scripts?
-jay
Follow ups
References