> 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.
It's not about having a named condition, it's about having a single
condition for a given schema reduction and tying that to all the
potentially affected bits. Any time the online schema contract phase is
being processed, we look at things marked as "removed," and only
actually remove them if their condition is satisfied. If two things are
affected by a given migration (say reducing two columns into one), then
neither column can be removed until they both pass the shared condition.
Another example:
class MergeNameFields(Condition):
def satisfied(self):
return name_is_empty() and display_name_is_empty()
...
class Instance(sqla.Model):
id = sqla.Integer()
uuid = sqla.String()
common_name = sqla.String()
name = RemovedField(original=sqla.String(),
condition=MergeNameFields())
display_name = RemovedField(original=sqla.String(),
condition=MergeNameFields())
In this example, the expand phase would add common_name if it's not in
the database. Our objects (and background migrations) would move things
from name and display_name into common_name (however that is to happen).
The contract phase would say "lookie, these two fields need to be
removed". On each, it would run the condition and only actually remove
the fields from the schema if the condition is satisfied.
We get bonus points for this approach because we could share and cache
the results of these conditions at startup and avoid running
migration-sensitive code in our objects once we know that everything has
been migrated.
--Dan
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
