<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 11:58 AM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">
<div class="im">On Sun, Jul 14, 2013 at 12:29 PM, Boris Pavlovic <span dir="ltr"><<a href="mailto:boris@pavlovic.me" target="_blank">boris@pavlovic.me</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Dolph, <div><br></div><div>Yes, I agree that there are some problems with sqlite and migrations.<br>
</div>
<div>But I am not agree with approach of fully removing sqlite. </div><div><br></div><div>It is pretty useful for testing. </div></div></blockquote><div><br></div></div><div>To be clear, I don't have any interest in dropping support for running keystone against sqlite as backend for development / testing. It's certainly useful for running functional tests in-memory. However, such databases don't need to be created by db_sync or using any migrations whatsoever.</div>

<div><br></div><div>It's the migrations themselves where I want to drop support for sqlite. No one is migrating production data in a sqlite database.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr">
<div><br></div><div>So the right approach that we are trying to provide in whole OpenStack is next:</div>
<div><br></div><div>1) Use alembic as migration tool (don't support sqlite in migrations)</div></div></blockquote><div><br></div></div><div>In my original email, I failed to cite where I got the idea (because I couldn't find a link, perhaps someone else knows of it?), but the same concern was expressed by some alembic-related documentation or blog post that I had recently read. I don't expect to see keystone making much progress towards switching to alembic until icehouse or even later. In the mean time, I'd like to do what we can to limit our pain while working with sqlaclhemy-migrate (which mostly involves writing entirely different code paths to handle sqlite's lack of support for proper schema evolution).</div>
</div></div></div></blockquote><div><br></div><div>From <a href="https://bitbucket.org/zzzeek/alembic">https://bitbucket.org/zzzeek/alembic</a>:</div><div><br></div><div>"""</div><div><ul class="" style="margin:10px 0px 0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px">
<li>Don't break our necks over SQLite's inability to ALTER things. SQLite has almost no support for table or column alteration, and this is likely intentional. Alembic's design is kept simple by not contorting its core API around these limitations, understanding that SQLite is simply not intended to support schema changes. While Alembic's architecture can support SQLite's workarounds, and we will support these features provided someone takes the initiative to implement and test, until the SQLite developers decide to provide a fully working version of ALTER, it's still vastly preferable to use Alembic, or any migrations tool, with databases that are designed to work under the assumption of in-place schema migrations taking place.</li>
</ul><div><font color="#333333" face="Arial, sans-serif"><span style="font-size:14px;line-height:20px">"""</span></font></div></div><div><font color="#333333" face="Arial, sans-serif"><span style="font-size:14px;line-height:20px"><br>
</span></font></div><div><font color="#333333" face="Arial, sans-serif"><span style="font-size:14px;line-height:20px">Moving to alembic still provides benefits (merging changesets with migration scripts is easier and that the tool is actively maintained), but migrations in SQLite isn't one of them.</span></font></div>
<div><font color="#333333" face="Arial, sans-serif"><span style="font-size:14px;line-height:20px"><br></span></font></div><div><font color="#333333" face="Arial, sans-serif"><span style="font-size:14px;line-height:20px">Doug</span></font></div>
<div><font color="#333333" face="Arial, sans-serif"><span style="font-size:14px;line-height:20px"><br></span></font></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>2) Test migrations in two ways:<br>
</div><div>a) run all migrations with real data against supported backends (mysql, psql) </div>

<div>b) test that models and migrations are synced in all backends (mysql, psql)</div></div></blockquote><div><br></div></div><div>+1</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div>3) Unit tests should be run against DB that was created from models (not from migrations)<br></div></div></blockquote><div><br></div></div><div>+1</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div></div><div>4) Unit tests should support all backends (sqlite also)<br></div></div></blockquote><div><br></div></div><div>+1</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div>
</div><div><br></div><div><br></div><div>If you are interested in this sphere I could try to describe current state in more words. </div></div></blockquote><div><br></div></div><div>I think we're already in complete agreement! I just wasn't clear in my original email (apologies!).</div>
<div><div class="h5">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div>
<div>Best regards,</div><div>Boris Pavlovic</div><div><div>
<div>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 13, 2013 at 12:19 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><br>
<br>
On 07/11/2013 01:12 PM, Dolph Mathews wrote:<br>
> Just as a general statement, outside the scope of openstack, I don't<br>
> think sqlite is intended to support schema evolution. From the sqlite<br>
> docs [1]: "SQLite supports a limited subset of ALTER TABLE. [...] It is<br>
> not possible to rename a column, remove a column, or add or remove<br>
> constraints from a table."<br>
><br>
> We've been through hell trying to support migrations on sqlite, because<br>
> we test against sqlite, and because we test our migrations... on sqlite.<br>
> So, we've already shot ourselves in the foot. We're clearly moving<br>
> towards gating against mysql + postgresql, so in the mean time, let's<br>
> limit the amount of effort we put into further support sqlite migrations<br>
> until we can safely rip it out altogether.<br>
><br>
> [1]: <a href="http://www.sqlite.org/lang_altertable.html" target="_blank">http://www.sqlite.org/lang_altertable.html</a><br>
<br>
</div></div>I agree. The reason to use sqlite in unitests and stuff is because it's<br>
easy and doesn't require users and system things and everything. If<br>
we're spending extra effort to maintain the simple thing, then it's<br>
probably not a simple thing.<br>
<br>
As an aside, (ignore the fact that I'm a former Drizzle core dev) it<br>
might be worthwhile taking 30 minutes one day and exploring a drizzle<br>
database test fixture. One of the things we did in drizzle was make it<br>
not need any bootstrapping and to work sanely with no config files ...<br>
so launching a drizzle on a spare port, running database tests against<br>
it and then deleting it should actually be super simple - and at the<br>
worst no harder than doing what glance does in their functional tests.<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></div>
<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></blockquote></div></div></div><span class=""><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</font></span></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></div>