On 6/15/15 9:21 AM, Philip Schwartz wrote:
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.
Request: Add the ability to verify migrations are completed prior to
contract.
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.
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.
After discussing this with Mike, there looks to be 3 options:
1. 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.
2. 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)
3. 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.
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.
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? ).
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.
__________________________________________________________________________
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
