<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 6/15/15 9:21 AM, Philip Schwartz
wrote:<br>
</div>
<blockquote
cite="mid:9D4BF6F0-E109-4B79-84D5-0409F4EA729D@rackspace.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
This weekend, I discussed the requested change at length with
Mike. I think before moving forward, we need a better
understanding of what is trying to be achieved.
<div class=""><br class="">
</div>
<div class="">Request: Add the ability to verify migrations are
completed prior to contract.</div>
<div class=""><br class="">
</div>
<div class="">As discussed here previously, I worked out a setup
using the .info dict of the Column’s that are to be removed or
Migrated. But came across and issue that is more concerning.</div>
<div class=""><br class="">
</div>
<div class="">In order to contract the DB, the columns need to be
removed from the Model Classes. We can do this just prior to
scanning the Model Classes to determine schema migrations, but
the columns would still exist in the Model Class for all other
loading of the model, i.e. at ORM query’s and such.</div>
<div class=""><br class="">
</div>
<div class="">After discussing this with Mike, there looks to be 3
options:</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">Remove the columns at contract time and also
build a mechanism to scan for the same .info entry at Query
time to prevent it from being used.</li>
<li class="">Remove the columns at contract time and create a
mechanism that on load of data models once the migration is
complete would remove the columns (forced restart of service
once migration is done will allow the ORM queries to no
longer see the column)</li>
<li class="">Build the controls into our process with a way of
storing the current release cycle information to only allow
contract’s to occur at a set major release and maintain the
column in the model till it is ready to be removed major
release + 1 since the migration was added.</li>
</ol>
<div class=""><br class="">
</div>
</div>
<div class="">Personally, for ease of development and
functionality, I think the best option is the 3rd as it will not
require reinventing the wheel around data loading and handling
of already loaded data models that could affect ORM queries.</div>
</blockquote>
<br>
Well one advantage to the way "contract" is totally automated here
is that as long as the ORM models have a column X present,
"contract" won't remove it. What problem would storing the
release cycle information solve ? (also by "store" you mean a DB
table? ). <br>
<br>
I'm writing out a spec for Neutron this week that reboots the OSM
concept without dropping the concept of versioned migration files
and versioning as I've discussed. As I've mentioned elsewhere i
hope to enhance Alembic's functionality so that Nova's current OSM
approach as well as the file/ version-number based approach can both
leverage the same codebase for generating the stream of
expand/contract steps.<br>
<br>
<br>
<br>
<br>
</body>
</html>