2013-07-26 1 views
1

자동 생성 된 Django South (0.7.6) 마이그레이션 파일에는 field의 고유 제한 조건을 삭제하고 다른 Django에 대한 외래 키가되는 단순 전달 마이그레이션이 포함되어 있습니다 모델. 그는 이노 엔진에서 실행 내 MySQL을 5.5 데이터베이스에서 실행되는Django South 마이그레이션 후 전체 테이블이 누락되었습니다.

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'])) 

, 그것은 테이블이 효율적으로 장고를 삭제하고, 눈에 보이지 않는 것을 의미 테이블

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

을 "이름을 실패"

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

이 데이터베이스는 복원이 마이그레이션을 다시 실행하고 5 회 반복,이 마이그레이션 그냥 우연히 실패하지 않았다는 것을 확신을 가지고.

제 질문은 : 무엇이 잘못 되었습니까?

답변

2

발견. 이것은 독특한, 일대일 MySQL의 테이블에서 수행 없는 고유성 제약, 간단한 외래 키 관계에 장고 관계,의 MyISAM 중 하나 또는 이노 변환 드문 조합으로 발생 , 왜냐하면 MySQL supports transactional schema alterations on neither이기 때문에 엔진이 작동합니다.

이 문제를 해결하기 위해 the advice of a kind fellow 다음에 나오는 db.alter_column 명령을 제거 했으므로 OneToOne 관계와 ForeignKey 관계 사이의 기본 스키마가 기능상 차이가 없음을 발견했습니다.