Thx Monty, jroll, smcginnis, zzzeek_ ...
-amrith -- Amrith Kumar Phone: +1-978-563-9590 On Wed, May 31, 2017 at 10:17 AM, Monty Taylor <mord...@inaugust.com> wrote: > On 05/31/2017 08:51 AM, Amrith Kumar wrote: > >> This email thread relates to[1], a change that aims to improve cross-SQL >> support in project schemas. >> >> I want to explicitly exclude the notion of getting rid of support for >> PostgreSQL in the underlying project schemas, a topic that was discussed at >> the summit[2]. >> >> In this change, the author (Thomas Bechtold, copied on this thread) makes >> the comment that the change "is not changing the schema. It just avoids >> implicit type conversion". >> >> It has long been my understanding that changes like this are not upgrade >> friendly as it could lead to two installations both with, say version 37 or >> 38 of the schema, but different table structures. In effect, this change >> breaks upgradability of systems. >> >> i.e. a deployment which had a schema from the install of Ocata would have >> a v38 table modules table with a default of 0 and one installed with Pike >> (should this change be accepted) would have a modules table with a default >> of False. >> > > I agree that if that was the case this would be bad. But I don't think > it's the case here. > > The datatype in the model is already Boolean. So I believe that means this > will be a tinyint in MySQL and likely a boolean in PG (I'm guessing) the > only change here is to the SQLA layer in what is being used in code - and > being more explicit seems good. > > So I think this is a win. > > I'm raising this issue on the ML because the author also claims (albeit >> not verified by me) that other projects have accepted changes like this. >> > > Thanks! I think this is an area we need to be careful in - and extra > eyeballs are a good thing. > > I submit to you that the upgrade friendly way of making this change would >> be to propose a new version of the schema which alters all of these tables >> and includes the correct default value. On a fresh install, with no data, >> the upgrade step with this new schema version would bring the table to the >> right default value and any system with that version of the schema would >> have an identical set of defaults. Similarly any system with v37 or 38 of >> the schema would have identical defaults. >> > > Yes - I agree - that would definitely be the right way to do this if there > was a model change. > > What's the advice of the community on this change; I've explicitly added >> stable-maint-core as reviewers on this change as it does have stable branch >> upgrade implications. >> >> -amrith >> >> [1] https://review.openstack.org/#/c/467080/ >> [2]https://etherpad.openstack.org/p/BOS-postgresql >> >> >> >> -- >> Amrith Kumar >> Phone: +1-978-563-9590 >> >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
