Open Stack

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 <alazarev at 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 <tmckay at 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 at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140201/79308a6a/attachment.html>