一日一技：如何让Django 的app migration重新与数据库同步

今天的文章，没有用过Django的同学可能难以理解我在说什么。但是如果你被Django的migration折腾过，那么你一定会感谢这篇文章。

当我们使用Django + MySQL开发网站服务的时候，我们应该始终使用Django来管理数据库，无论是增加字段，删除字段，修改字段，都应该直接修改Django工程 app里面对应的 models.py文件，不应该再手动直接修改数据库。

但这种理想的情况有时候会被打破。我最近遇到了这样一种情况：

出于安全考虑，我把线上的MySQL数据库禁用了 drop的权限。但由于我修改了 models.py文件中的字段，于是触发了 drop字段的操作，由于没有权限，导致Django在migration线上数据库的时候报错。

由于上线时间紧急，当时我直接通过执行SQL语句在线上MySQL中创建了对应的数据表和字段。

现在就出现问题了：

1. 首先，Django的web服务能够正常工作，因为数据表是完全正确的。
2. app的migration一共有10条，在进行到第6条的时候报错。剩下的4步无法继续执行。
3. 数据库经过人工修改，看起来像是把所有migration都执行完的样子，但实际上最后4步是通过执行SQL语句手动创建的。
4. 如果不增删改新的字段，那么到目前为止不会有什么问题。但是如果增加修改了新的字段，migration将会始终失败。除非每一次都手动修改数据库。

现在的情况就是数据库与Migration不一致，可以使用下面的命令重新同步migration和数据库。

# 清除迁移历史记录
python manage.py migrate --fake app_name zero

# 查看当前的migration进度，此时文件前的 [x] 变成了[ ]
python manage.py showmigrations app_name

#删除app-migrations下除__init__.py的其他文件

#执行makemigrations，程序会再次为这个app 生成 0001_initial.py 文件

python manage.py makemigrations app_name

# 把当前数据库的状态作为初始状态
python manage.py migrate --fake-initial app_name

从现在开始，你再次对数据库进行更改以后，重新make migration，所有新的操作都会基于当前的数据库状态继续进行，migration和数据库又重新同步了。