On Tue, Jul 16, 2013 at 12:55 AM, Michael Still <mi...@stillhq.com> wrote: > On Tue, Jul 16, 2013 at 4:17 PM, Thomas Goirand <z...@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@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev