Open Stack

On Thu, Feb 19, 2015, Matthew Booth <mbooth at 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