Jay, Yep we shouldn't use migrations for sqlite at all.
The major issue that we have now is that we are not able to ensure that DB schema created by migration & models are same (actually they are not same). So before dropping support of migrations for sqlite & switching to model based created schema we should add tests that will check that model & migrations are synced. (we are working on this) Best regards, Boris Pavlovic On Fri, Jan 31, 2014 at 7:31 PM, Andrew Lazarev <alaza...@mirantis.com>wrote: > Trevor, > > Such check could be useful on alembic side too. Good opportunity for > contribution. > > Andrew. > > > On Fri, Jan 31, 2014 at 6:12 AM, Trevor McKay <tmc...@redhat.com> wrote: > >> Okay, I can accept that migrations shouldn't be supported on sqlite. >> >> However, if that's the case then we need to fix up savanna-db-manage so >> that it checks the db connection info and throws a polite error to the >> user for attempted migrations on unsupported platforms. For example: >> >> "Database migrations are not supported for sqlite" >> >> Because, as a developer, when I see a sql error trace as the result of >> an operation I assume it's broken :) >> >> Best, >> >> Trevor >> >> On Thu, 2014-01-30 at 15:04 -0500, Jay Pipes wrote: >> > On Thu, 2014-01-30 at 14:51 -0500, Trevor McKay wrote: >> > > I was playing with alembic migration and discovered that >> > > op.drop_column() doesn't work with sqlite. This is because sqlite >> > > doesn't support dropping a column (broken imho, but that's another >> > > discussion). Sqlite throws a syntax error. >> > > >> > > To make this work with sqlite, you have to copy the table to a >> temporary >> > > excluding the column(s) you don't want and delete the old one, >> followed >> > > by a rename of the new table. >> > > >> > > The existing 002 migration uses op.drop_column(), so I'm assuming it's >> > > broken, too (I need to check what the migration test is doing). I was >> > > working on an 003. >> > > >> > > How do we want to handle this? Three good options I can think of: >> > > >> > > 1) don't support migrations for sqlite (I think "no", but maybe) >> > > >> > > 2) Extend alembic so that op.drop_column() does the right thing (more >> > > open-source contributions for us, yay :) ) >> > > >> > > 3) Add our own wrapper in savanna so that we have a drop_column() >> method >> > > that wraps copy/rename. >> > > >> > > Ideas, comments? >> > >> > Migrations should really not be run against SQLite at all -- only on the >> > databases that would be used in production. I believe the general >> > direction of the contributor community is to be consistent around >> > testing of migrations and to not run migrations at all in unit tests >> > (which use SQLite). >> > >> > Boris (cc'd) may have some more to say on this topic. >> > >> > Best, >> > -jay >> > >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
