<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 6/10/15 4:34 PM, Dan Smith wrote:<br>
</div>
<blockquote cite="mid:55789F39.90408@danplanet.com" type="cite">
<blockquote type="cite">
<pre wrap="">The remaining work is to have a way of preventing database contracts
Foreign Keys.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
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.<br>
<br>
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 "
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
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. <br>
<br>
<br>
</body>
</html>