<div dir="ltr">Boris,<div><br></div><div>Sorry for the offtopic.</div><div>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.</div>
<div>Can you point to some discussion threads?</div><div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 1, 2014 at 2:19 AM, Boris Pavlovic <span dir="ltr"><<a href="mailto:bpavlovic@mirantis.com" target="_blank">bpavlovic@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Jay, <div><br></div><div>Yep we shouldn't use migrations for sqlite at all.</div><div><br></div><div>
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). </div>
<div><br></div><div>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. </div><div>(we are working on this)</div>
<div><br></div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 31, 2014 at 7:31 PM, Andrew Lazarev <span dir="ltr"><<a href="mailto:alazarev@mirantis.com" target="_blank">alazarev@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Trevor,<div><br></div><div>Such check could be useful on <font face="arial, sans-serif">alembic side too. Good opportunity for contribution.</font><span><font color="#888888"><br>
<div><br></div><div>Andrew.</div></font></span></div></div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Jan 31, 2014 at 6:12 AM, Trevor McKay <span dir="ltr"><<a href="mailto:tmckay@redhat.com" target="_blank">tmckay@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Okay, I can accept that migrations shouldn't be supported on sqlite.<br>
<br>
However, if that's the case then we need to fix up savanna-db-manage so<br>
that it checks the db connection info and throws a polite error to the<br>
user for attempted migrations on unsupported platforms. For example:<br>
<br>
"Database migrations are not supported for sqlite"<br>
<br>
Because, as a developer, when I see a sql error trace as the result of<br>
an operation I assume it's broken :)<br>
<br>
Best,<br>
<br>
Trevor<br>
<br>
On Thu, 2014-01-30 at 15:04 -0500, Jay Pipes wrote:<br>
> On Thu, 2014-01-30 at 14:51 -0500, Trevor McKay wrote:<br>
> > I was playing with alembic migration and discovered that<br>
> > op.drop_column() doesn't work with sqlite. This is because sqlite<br>
> > doesn't support dropping a column (broken imho, but that's another<br>
> > discussion). Sqlite throws a syntax error.<br>
> ><br>
> > To make this work with sqlite, you have to copy the table to a temporary<br>
> > excluding the column(s) you don't want and delete the old one, followed<br>
> > by a rename of the new table.<br>
> ><br>
> > The existing 002 migration uses op.drop_column(), so I'm assuming it's<br>
> > broken, too (I need to check what the migration test is doing). I was<br>
> > working on an 003.<br>
> ><br>
> > How do we want to handle this? Three good options I can think of:<br>
> ><br>
> > 1) don't support migrations for sqlite (I think "no", but maybe)<br>
> ><br>
> > 2) Extend alembic so that op.drop_column() does the right thing (more<br>
> > open-source contributions for us, yay :) )<br>
> ><br>
> > 3) Add our own wrapper in savanna so that we have a drop_column() method<br>
> > that wraps copy/rename.<br>
> ><br>
> > Ideas, comments?<br>
><br>
> Migrations should really not be run against SQLite at all -- only on the<br>
> databases that would be used in production. I believe the general<br>
> direction of the contributor community is to be consistent around<br>
> testing of migrations and to not run migrations at all in unit tests<br>
> (which use SQLite).<br>
><br>
> Boris (cc'd) may have some more to say on this topic.<br>
><br>
> Best,<br>
> -jay<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>