On 6/10/15 4:34 PM, Dan Smith wrote:
The remaining work is to have a way of preventing database contracts
Foreign Keys.
I'm not sure if SQLAlchemy will balk at this or not, but we could do
something like:


   class NameRemovedCondition(object):
       def satisfied(self):
           # Check to see if "name" has been fully migrated


   class Instance(sqla.Model):
       id = sqla.Integer()
       uuid = sqla.String()
       name = RemovedField(original=sqla.String(),
                         condition=NameCondition())


Then the schema migration bit can catch RemovedField entries, know what
they were (so that it can leave that bit alone), and only remove them
when condition is satisfied. Complex migrations that affect multiple
columns can share a condition that checks the full situation.
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.

The need to put directives into our models that send hints along to the migration tool is also something I talked about in my wrapup email as something which works against the desired goal of a purely "declarative" migration approach (my quote was " Without any place to establish migration behaviors declaratively other than the model itself means that I can imagine that we ultimately would have to start adding "hints" to our models, like "use_migration_style_X_on_mysql" to mapped classes"). This is of course entirely doable, but IMO these aren't "declarative" migrations.


__________________________________________________________________________
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

Reply via email to