Open Stack

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 <dms at danplanet.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev