Migration 091 broken for SQLite
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
High
|
Rick Harris |
Bug Description
Migration 091 swallows exceptions generated by SQLAlchemy-Migrate leaving the database in an inconsistent state, in particular, leaving a 'migration_tmp` table around that will cause future migrations to fail.
The failure seems to be:
1. The script attempts to drop foreign-key constraints. The SQLAlchemy-Migrate SQLite driver raises a NotSupportedError since ALTER TABLE DROP CONSTRAINT is not supported directly by SQLite and SQLAlchemy-MIgrate doesn't have work-around code in place for this.
File "/usr/local/
"%s; see http://
NotSupportedError: SQLite does not support ALTER TABLE DROP CONSTRAINT; see http://
The migration script simply ignores this error by swallowing the exception.
2. After performing the data fix-up, the script attempts to re-create the new foreign-key constraints. The causes a different exception in SQLAlchemy-Migrate:
File "/usr/local/
if self._requires_
File "/usr/local/
lc_value = value.lower()
AttributeError: 'int' object has no attribute 'lower'
This appears to be caused by us not having dropped the original constraint which happens to have the name 0 which is misinterpreted as an integer causing the `lower()` to fail.
This exception prevents the SQLAlchemy-Migrate code from emitting the ALTER TABLE RENAME or DROP TABLE for `migration_tmp` leaving it hanging around for the next migration to hit and fail (in this case 098 seems to be the next failure for me).
Possible solutions:
1. Switch to Alembic (and fix it's SQLite support in the process)
2. Write a 091_sqlite_
3. Fix SQLAlchemy-MIgrate to support DROP CONSTRAINT by using a tmp table as well as possibly fixing SQLAlchemy's cast code (BEST FOR UPSTREAM)
Changed in nova: | |
importance: | Undecided → Medium |
importance: | Medium → High |
assignee: | nobody → Rick Harris (rconradharris) |
Changed in nova: | |
milestone: | none → grizzly-1 |
status: | Fix Committed → Fix Released |
Changed in nova: | |
milestone: | grizzly-1 → 2013.1 |
The problem turned out to be me using SQLAlchemy 0.7.2 instead of 0.7.8. Upgrading fixed the issue.
That said, the handling of exceptions in the script seem overly broad, so I'm going to propose a patch which clamps down on which exceptions are truly acceptable, since catching arbitrary exceptions just causes failures in future migrations due to DB inconsistency.