Django 版本 1.9,先描述一下我遇到的问题。
# 假设这是我的 Model
class StudentCourse(models.Model):
user = xxx
course = xxx
class Meta:
unique_together = ('user', 'course')
我在修改 Model 时,不仅 Alter 了 unique_together,并且 Delete 了原来 unique_together 里的 column,造成 migrate 出错。
django.core.exceptions.FieldDoesNotExist: StudyRecord has no field named u'chapter'
# 假设这是我更改过后的 Model
class StudentCourse(models.Model):
human = xxx
some_stuff = xxx
class Meta:
unique_together = ('human', 'some_stuff')
照理来说,修改完 Model,makemigrations & migrate
即可。为什么会崩溃呢?
经过我的试错和分析,发现如果完全按照 Django 生成的 migration 文件来执行操作的话,顺序是存在问题的。
按照我上面的操作,Django 会先删除 user & course 这两个字段,再去 Alter unique_together,这个操作等于是在 Alter 一个不存在的 column ,那么就会崩溃。
正确的做法是,先 Alter constraint,然后再删除 user & course 。
涉及到 Django Model 的修改,尽量不把各种操作混在一起。这样也许麻烦,但最稳。如果你看得懂 Django 生成的 migration 文件,当然也可以自己调整顺序。
由于 migrate 崩溃了,此时 migrate 没有成功,我在检查数据库后发现 column 也没有被删除。接着我开始恢复。
-
我把错误的 migration 文件删除,修改 Model ,此时新增 human & some stuff 两个字段,并且修改了 unique_together, makemigrations & migrate。
-
删除 user & course,makemigrations & migrate ,问题解决。
此外,还有一个 migrate 指令可以了解一下。
python manage.py migrate --fake your_app_name your_migration_name
这个指令是做什么用的呢?Django 在每次 migrate 成功以后,会存储项目中各个 app 的 migrate 状态,比如我成功 migrate 了 0055_auto_xxx 文件,它就会给这个里程碑打个勾,记录你 migrate 到了这里。(应该还有其它用处,我没深入了解)
如果你有回退的需要,可以将 your_migration_name
替换为你的 migration 文件名,然后在不同状态之间切换。
去掉 --fake
的话,就是真实的回退。恭喜你踏出从删库到跑路的第一步。
对了,这个指令可以显示你项目的 migration 状态,正常情况下应该都是 x,表示你项目里的 app 都执行过了 migrate 。
python manage.py showmigrations
网友评论