Open Stack

On 06/10/15 at 01:34pm, Dan Smith 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.

+1.  This code has been ready to go for a bit now and just happened to 
miss a merge deadline last cycle.  Let's start there before solving the 
next part.

>
>> 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