[openstack-dev] [savanna] Alembic migrations and absence of DROP column in sqlite

Eugene Nikanorov enikanorov at mirantis.com
Sat Feb 1 10:09:36 UTC 2014


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 <bpavlovic at 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 <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
>>>
>>
>>
>
> _______________________________________________
> 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/53a9935d/attachment.html>


More information about the OpenStack-dev mailing list