使用现有表迁移时，Django 的 --fake-initial 不起作用答案

【问题标题】：Django's --fake-initial doesn't work when migrating with existing tables使用现有表迁移时，Django 的 --fake-initial 不起作用
【发布时间】：2020-07-22 11:00:52
【问题描述】：

我正在将一个项目从 Django 1.1 迁移到 Django 3.0 我已完成该项目。当我在新转换的项目中将生产转储转储到本地时，我得到"Table already exists"。

这就是我正在做的事情。

mysql> create database xyx;

docker exec -i <container-hash> mysql -u<user> -p<password> xyx < dbdump.sql

然后我运行迁移，因为我必须对之前给定的模型进行一些更改。

./manage.py migrate --fake-initial

这是我得到的输出

    _mysql.connection.query(self, query)
django.db.utils.OperationalError: (1050, "Table 'city' already exists")

那么，该怎么办？

【问题讨论】：

可能不是在初始迁移时创建了一个或多个表？ --fake-initial 仅当迁移文件在迁移类中具有 initial=True 时才会考虑。
当我阅读文档时，我完全不明白那行是什么意思。那么你有解决这个特殊问题的方法吗？
查看您的迁移 - 第一个迁移确实将属性 initial 设置为 True。这将被跳过，但如果您有下一个迁移创建 City 没有此属性的模型 - Django 将不会跳过它并引发错误。我认为您最终的解决方案是通过从所有非初始表中删除表创建来手动更改迁移。

标签： django django-migrations

【解决方案1】：

好的男孩和女孩，这是我解决这个问题的方法。

我转储了整个数据库。

docker exec -i <container-hash> mysql -u<username> -p<password> <dbname> < dump.sql

现在我列出了我使用的所有迁移

./manage.py showmigrations <app-name>

这将为我提供我已应用的所有迁移的列表，现在通过检查迁移，我意识到从第 7 次迁移到第 30 次迁移我已经完成了我的更改。

这是任何系统管理员都可以用不到 4 行 bash 脚本编写脚本来完成的繁琐部分。您可以使用此命令生成任何迁移的原始 SQL。

./manage.py sqlmigrate <app-name> <migration-name> > changes-i-made.sql

现在我已经创建了我的 changes-i-made.sql 文件，我需要再运行这个脚本 22 次，但是使用 >> 否则每次你使用单个 > 运行命令时，它都会继续覆盖你的更改文件。

现在，一旦您的所有迁移更改都记录在文件中，打开您的 sql shell 连接到数据库并开始粘贴更改或执行一些 sql 魔术以直接从文件中选择所有更改。

一旦你完成了，继续伪造所有的迁移，因为你不需要 Django 来做你已经做过的。

./manage.py migrate --fake

然后登录到您的生产实例，并准备好与您的高级团队负责人发生关系，他说您做不到。

我刚刚检查了这种方法是否有效，以及未来的迁移是否有效，所以我创建了一个，一切都变得轻而易举。

【讨论】：