Open Stack

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.


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