On Thu, Feb 19, 2015, Matthew Booth <mbo...@redhat.com> wrote: > Assuming this configurability is required, is there any way we can > instead use it to control a unique constraint in the db at service > startup? This would be something akin to a db migration. How do we > manage those?
Ignoring if this particular feature is useful or not, this is possible. With sqlalchemy-migrate, there could be code to check the config option at startup and add/remove the unique constraint. This would leave some schema management out of the existing scripts, which would be mildly ugly. With my online schema changes patch, this is all driven by the model. Similar code could add/remove the unique constraint to the model. At startup, the schema could be compared against the model to ensure everything matches. Adding/removing a unique constraint at any time leaves open some user experience problems with data that violates the constraint preventing it from being created. Presumably a tool could help operators deal with that. All that said, it's kind of messy and nontrivial work, so I'd avoid trying to support a feature like this if we really don't need to :) JE __________________________________________________________________________ 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
