<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">This email thread relates to[1], a change that aims to improve cross-SQL support in project schemas.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">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].<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">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".<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">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.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">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.<br></div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">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.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">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.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">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.<br></div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">-amrith<br></div><div class="gmail_default" style="font-family:courier new,monospace"><br>[1] <a href="https://review.openstack.org/#/c/467080/">https://review.openstack.org/#/c/467080/</a><br clear="all"></div><div><div class="gmail_signature"><span style="font-family:courier new,monospace"></span><div style="font-family:courier new,monospace;display:inline" class="gmail_default">​[2]<a href="https://etherpad.openstack.org/p/BOS-postgresql">https://etherpad.openstack.org/p/BOS-postgresql</a><br>​</div><div style="font-family:courier new,monospace" class="gmail_default">​​</div><br><span style="font-family:courier new,monospace">--</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">Amrith Kumar</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">Phone: +1-978-563-9590</span><br><br></div></div>
</div>