Drop Credentials constraint migration does not specify schema
Bug #1186353 reported by
Adam Young
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Medium
|
Adam Young |
Bug Description
THe SQL executed for the Mysql drop contraint is
select CONSTRAINT_NAME from "
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.
Changed in keystone: | |
assignee: | nobody → Adam Young (ayoung) |
Changed in keystone: | |
importance: | Undecided → Medium |
Changed in keystone: | |
milestone: | none → havana-2 |
status: | Fix Committed → Fix Released |
Changed in keystone: | |
milestone: | havana-2 → 2013.2 |
To post a comment you must log in.
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]