Check schema when dropping constraints.

MySQL constraints are not named like others.

Previous to this patch, we were looking up the names in MySQL's
INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS table, but were
neglecting to also check the Schema. The same table
could be in multiple schemas; as an example a unit test
run on the same machine as devstack in two different schemas
but the same RDBMS.

This patch uses a better approach. Sqlalchemy knows about the
name of the constraint, it just doesn't use it in the
drop statement by default. The Constraint objects from
the main sqlalchemy package don't do drops, only those out
of the migrate package. This patch finds the name of the
constraint in the constraint bound to the table and passes it
to the migrate ForeignKeyConstraint to use in the drop statement

Bug 1186353

Change-Id: Ida2184021de9dd220a36507a8a625cf4210d17f7

0 files changed, 0 insertions, 0 deletions