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

Django's --fake-initial doesn't work when migrating with existing tables

我正在将项目从 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")

那么,怎么办?

好的男孩女孩们,这是我用来解决这个问题的方法。

我转储了整个数据库。

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

然后登录到您的生产实例,并准备好与您的高级团队领导做爱,他说您做不到。

我只是检查了这种方法是否有效以及未来的迁移是否有效,所以我创建了一个,一切都像 breeze。