Open Stack

On Tue, Jul 16, 2013 at 12:55 AM, Michael Still <mikal at stillhq.com> wrote:
> On Tue, Jul 16, 2013 at 4:17 PM, Thomas Goirand <zigo at debian.org> wrote:
>
>> Could you explain a bit more what could be done to fix it in an easy
>> way, even if it's not efficient? I understand that ALTER doesn't work
>> well. Though would we have the possibility to just create a new
>> temporary table with the correct fields, and copy the existing content
>> in it, then rename the temp table so that it replaces the original one?
>
> There are a bunch of nova migrations that already work that way...
> Checkout the *sqlite* files in
> nova/db/sqlalchemy/migrate_repo/versions/
>
> Cheers,
> Michael
>
> --
> Rackspace Australia
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

If we really want to support the concept of SQLite migrations, the way
nova does it seems to be the most sane.  I'm not 100% convinced that
SQLite migrations are worth supporting, but then again, I am not the
target to use them (besides in a simple development capacity, and I
still validate against MySQL/Postgres mostly).  If there is a demand
for SQLite, I'd say Michael has hit it on the head and the way Nova
handles this is a fairly clean mechanism and far more supportable over
the short and medium term(s) compared to working around migrate issues
with SQLite and the limited Alter support.

In one of the discussions in IRC I had offered to help with the effort
of moving away from SQLite migration testing; if the nova-way is the
way we want to go, I'll be happy to help contribute to that.

Cheers,
Morgan Fainberg