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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
