Boris, Sorry for the offtopic. Is switching to model-based schema generation is something decided? I see the opposite: attempts to drop schema generation based on models in favor of migrations. Can you point to some discussion threads?
Thanks, Eugene. On Sat, Feb 1, 2014 at 2:19 AM, Boris Pavlovic <bpavlo...@mirantis.com>wrote: > 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev