Drop Credentials constraint migration does not specify schema

[Adam Young]

THe SQL executed for the Mysql drop contraint is

select CONSTRAINT_NAME from "
                    "INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS "
                    "where table_name = 'credential'

However, if there are multipl databases which each have a constraints table, this will select all of the constraints for all of the tables. THe query needs to be scoped in by the name of the schema:

So an additional CONSTRAINT_SCHEMA = `keystone` needs to be in the SQL (assuming the database name is keystone).

This just causes the migration to fail, but does not otherwise negatively effect the database.

[Brant Knudson (blk-u)]

I fixed a similar problem for DB2.

I looked up the constraint name... it was in the table structure.

Sqlalchemy did know the name of the constraint, but it just didn't use that name when dropping.

Here's the interesting bit: [fk.name for fk in table.constraints if column.name in fk.columns]

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/31249

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/31249
Committed: http://github.com/openstack/keystone/commit/e97262d21d3fce44201732eb409d24caaa11e026
Submitter: Jenkins
Branch: master

commit e97262d21d3fce44201732eb409d24caaa11e026
Author: Adam Young <email address hidden>
Date: Tue Jun 4 10:26:03 2013 -0400

    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