← Back to team overview

openstack team mailing list archive

Re: GLANCE: How to deal with SQLAlchemy-migrate problems


On Mon, Mar 21, 2011 at 5:42 PM, Brian Schott <bfschott@xxxxxxxxx> wrote:
> 1.a.) Not yet, but our branch unit tests (when we get there) will certainly test the architecture-related columns we added to instances, instance_types, and compute_node tables.
> 1.b) Is that a unit test responsibility or an integration test farm with different "typical" configurations that gets built, deployed, populated, and tested?  Agree it should happen before a branch gets merged.

Either one :) Having a test for scenarios where a column is moved from
one table to another is critical, IMHO, as failing that test
introduces a data loss bug, which is unacceptable to me.

> 2) They were pretty simple changes, so I just replicated from a previous python script examples in migrate_repo/versions.
> The point I was making that I did what anybody in a hurry will do, crib from the previous example.  I just added downgrade() because the example I followed didn't do that.  We can be propagating bad habits.  Realize, this is Nova, not Glance, so sorry if off topic.

No worries at all. Nova hasn't seen these issues (yet) for two reasons:

a) No test cases for the migrations
b) None of the models in Nova have a column that is created with
index=True. The index=True creates a secondary index on the column. In
the case of SQLite, this leads to the bug (issue 117 in sa-migrate)
described in the original post when you try to alter the table with a
Python migrate script.

Anyway, here's the good news (I hope!) :)

It occurred to me sometime as I slept last night that I might be able
to have *both* a Python migrate script *and* a SQL migrate script
(just for SQLite) that would be picked up properly by sa-migrate for
the same database version. After reviewing the code this morning, I
believe this is true. I'm testing the theory out this morning and will
update this thread with what I find.