Open Stack

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.

-Ph




On Jun 10, 2015, at 5:16 PM, Dan Smith <dms at danplanet.com<mailto:dms at danplanet.com>> wrote:

Well as long as you want to be able to load data and perform updates on
Instance.name using normal ORM patterns, you'd still have that column
mapped, if you want to put extra things into it to signal your migration
tool, there is an .info dictionary available on the Column that you can
use to do that.  A function like "removed_field()" can certainly wrap
around a normal column mapping and populate a hint into the .info
dictionary that online migrations will pick up on.

I intentionally didn't (try to) define RemovedField because I figured it
might contain some nasty proxy bits to make it continue to work.
However, glad to hear that there is already a provision here that we can
use -- that sounds perfect.

--Dan

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150615/fe47a445/attachment.html>