Open Stack

On 07/16/2013 01:50 PM, Dolph Mathews wrote:
> "Make it work" is an entirely different goal than "make a
> production-ready deployment." If your goal in using sqlite is just to
> "make it work" then I'm not sure that I would expect such an install to
> survive to the next release, anyway... rendering migration support as a
> nice-to-have. I can't imagine that any end users would be happy with a
> sqlite-based deployment for anything other than experimentation and testing.

In that case, IMO we should strongly state that fact, and don't let our
users believe that SQLite is supported (my view is that if upgrades
aren't, then it's as if SQLite wasn't supported at all).

>     If the support for SQLite (db upgrades) has to go, I will understand and
>     adapt. I haven't and probably wont find the time for doing the actual
>     work to support SQLite upgrades, and therefore, it probably is easier
>     for me to state, though, I believe it is my duty to raise my concerns,
>     and tell that I do not support this decision.
> 
> I'm glad you spoke up

Thanks! :)

>     What direction do you think this should take? Your thoughts?
> 
> 
> I'd still like to pursue dropping support for sqlite migrations, albeit
> not as aggressively as I would have preferred. With a stakeholder, I
> think it's requisite to continue support through Havana. Perhaps at the
> fall summit we can evaluate our position on both alembic and sqlite
> migrations.

Could you explain a bit more what could be done to fix it in an easy
way, even if it's not efficient? I understand that ALTER doesn't work
well. Though would we have the possibility to just create a new
temporary table with the correct fields, and copy the existing content
in it, then rename the temp table so that it replaces the original one?

Cheers,

Thomas