Вся таблица отсутствует после миграции Django South

Question

В автоматически сгенерированном файле миграции Django South (0.7.6) он содержит простую переадресацию, которая удаляет уникальное ограничение на field, а затем делает поле внешним ключом для другого Django модель.

class Migration(SchemaMigration): 

    def forwards(self, orm): 

     # Removing unique constraint on 'model2', fields ['field'] 
     db.delete_unique('app2_model2', ['field_id']) 

     # Changing field 'model2.field' 
     db.alter_column('app2_model2', 'field_id', self.gf('django.db.models.fields.related.ForeignKey')(null=True, to=orm['app1.model1'])) 

Когда это выполняется на моем MySQL 5.5 базы данных работает на движке InnoDB, он «не удается переименовать» таблицу

... 
File "/opt/python/bundle/3/app/apps/app2/migrations/0020_auto__chg_field_model2_field__del_unique_model2_field__chg_field_model2.py", line 19, in forwards 
    db.alter_column('app2_model2', 'field_id', self.gf('django.db.models.fields.related.ForeignKey')(null=True, to=orm['app1.model1'])) 
File "/opt/python/run/venv/lib/python2.6/site-packages/south/db/generic.py", line 44, in _cache_clear 
    return func(self, table, *args, **opts) 
File "/opt/python/run/venv/lib/python2.6/site-packages/south/db/generic.py", line 487, in alter_column 
    self.delete_foreign_key(table_name, name) 
File "/opt/python/run/venv/lib/python2.6/site-packages/south/db/generic.py", line 44, in _cache_clear 
    return func(self, table, *args, **opts) 
File "/opt/python/run/venv/lib/python2.6/site-packages/south/db/generic.py", line 780, in delete_foreign_key 
    "constraint": self.quote_name(constraint_name), 
File "/opt/python/run/venv/lib/python2.6/site-packages/south/db/generic.py", line 273, in execute 
    cursor.execute(sql, params) 
File "/opt/python/run/venv/lib/python2.6/site-packages/django/db/backends/mysql/base.py", line 114, in execute 
    return self.cursor.execute(query, args) 
File "/opt/python/run/venv/lib/python2.6/site-packages/MySQLdb/cursors.py", line 174, in execute 
    self.errorhandler(self, exc, value) 
File "/opt/python/run/venv/lib/python2.6/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler 
    raise errorclass, errorvalue 
django.db.utils.DatabaseError: (1025, "Error on rename of './ebdb/#sql-260e_45b9' to './ebdb/app2_model2' (errno: 150)") 

, что означает, что таблица эффективно стирается, и невидимый для Django:

... 
    cursor.execute(sql, params) 
File "/opt/python/run/venv/lib/python2.6/site-packages/django/db/backends/mysql/base.py", line 114, in execute 
    return self.cursor.execute(query, args) 
File "/opt/python/run/venv/lib/python2.6/site-packages/MySQLdb/cursors.py", line 174, in execute 
    self.errorhandler(self, exc, value) 
File "/opt/python/run/venv/lib/python2.6/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler 
    raise errorclass, errorvalue 
DatabaseError: (1146, "Table 'ebdb.app2_model2' doesn't exist") 

база данных была восстановлена, и эта миграция была повторно запустить, повторяется пять раз, с уверенностью сказать, что эта миграция не только никак не случайно.

Мой вопрос: что пошло не так?

Answer 1

Обнаружили проблему. Это происходит с редким сочетанием преобразования уникального, один-к-одному Джанго отношения к простым внешним ключу отношений с не ограничений уникальности, сделанных на столе MySQL, либо MyISAM или InnoDB , т.к. MySQL supports transactional schema alterations on neither, даже если двигатель делает.

Чтобы решить эту проблему, я просто удалил команды db.alter_column, следуя the advice of a kind fellow, который не обнаружил функциональных отличий в базовой схеме между отношениями OneToOne и отношением ForeignKey.