Drop Credentials constraint migration does not specify schema

Bug #1186353 reported by Adam Young on 2013-05-31
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Medium
Adam Young

Bug Description

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.

Adam Young (ayoung) on 2013-05-31
Changed in keystone:
assignee: nobody → Adam Young (ayoung)
Brant Knudson (blk-u) wrote :

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]

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

Changed in keystone:
status: New → In Progress

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

Changed in keystone:
status: In Progress → Fix Committed
Dolph Mathews (dolph) on 2013-06-10
Changed in keystone:
importance: Undecided → Medium
Thierry Carrez (ttx) on 2013-07-17
Changed in keystone:
milestone: none → havana-2
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2013-10-17
Changed in keystone:
milestone: havana-2 → 2013.2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers