首页 文章

Django South迁移后缺少整个表格

提问于
浏览
1

在自动生成的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']))

当在InnoDB引擎上运行的MySQL 5.5数据库上执行该操作时,它“无法重命名”该表

...
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")

数据库已恢复,重新运行此迁移,重复运行五次,并确信此迁移不会巧合地失败 .

我的问题是:出了什么问题?

1 回答

  • 2

    发现了问题 . 这种情况发生在罕见的组合中,即将一个唯一的,一对一的Django关系转换为简单的外键关系,没有唯一性限制,在MySQL表,MyISAM或InnoDB上完成,因为MySQL supports transactional schema alterations on neither,即使引擎也是如此 .

    为了解决这个问题,我刚刚删除了 db.alter_column 命令,在the advice of a kind fellow之后,他们发现OneToOne关系和ForeignKey关系之间的底层模式没有功能差异 .

相关问题