I like the idea of having a named condition, but the issue is how to maintain and control multiple of these conditions in a system that will use model against current schema to determine changes.
I also agree that we should get the current patch in as soon as possible and can move my -1 as a hold from it if others don’t mind it going as is while we work on the next part. I have updated the patchset to pass check’s this afternoon. -Ph > On Jun 10, 2015, at 4:34 PM, Dan Smith <[email protected]> wrote: > >> The remaining work is to have a way of preventing database contracts >> from running until data migrations that the column interacts with are >> complete, this is not an easy problem to solve as the goal of the >> online migrations is to do pure model based schema migrations and >> there is no way of currently identifying when a data migration has >> taken place and a contract is safe to perform. > > I'd still like to see what we have done so far merged as soon as > possible. That facilitates testing the main goal of it, which is > actually moving the schema along. It's experimental and completely > optional, and should have a "may eat your lunch" warning anyway. > >> The first thought I had was to default to a requirement of a data >> migration removing data from a column and have the default check of >> the contract be one of verifying that the column is currently empty. >> This has the issue of not working in all cases, especially around >> 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. > > Like I said, I'd like to get the existing patch merged so that we can > discuss options for this remaining bit in a smaller scope. > > --Dan > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
