修改Django迁移文件还是使用--fake参数解决表重命名迁移报错？

方案可行性判断 #

你认为--fake不适用于当前场景的判断完全正确：

• --fake仅会在Django的迁移记录表中标记迁移已执行，不会实际修改数据库结构。你本次迁移包含外键修改等需要真实执行的操作，对整个迁移文件使用--fake会导致这些必要变更无法落地，最终出现模型定义与数据库结构不匹配的问题，后续维护隐患极大。
• 如果仅对错误的建表/删表操作单独使用--fake，需要先拆分迁移文件，操作复杂度高，也容易留下迁移历史不一致的问题。

手动修改迁移文件的风险与最优调整方式 #

直接调换DeleteModel和CreateModel的顺序存在严重风险：先执行DeleteModel会直接删除现有tblFailureTypes表，所有存量数据都会丢失，绝对不能这么操作。

你遇到的问题本质是Django无法自动识别你是要重命名模型类，保留原有表结构和数据，误以为你是要删除旧模型、新建同名表的新模型，正确的迁移调整方式如下：

1. 删掉自动生成的CreateModel和DeleteModel两段操作
2. 替换为一行操作：

migrations.RenameModel(old_name="FailureTypes", new_name="FailureType")

这个操作是Django官方提供的模型重命名专用操作，只会修改Django内部的模型映射关系，不会改动底层表结构和存量数据，完全适配你的场景。

手动调整迁移文件是Django官方允许的常规操作，只要你明确每个操作对应的数据库行为，不存在额外风险，是当前场景下的最优解。

无修改迁移文件权限的替代方案 #

如果你确实没有修改迁移文件的权限，可以采用分步迁移的方案规避报错：

1. 临时将新FailureType模型的managed属性设置为False，重新生成迁移，此时Django不会尝试创建已存在的tblFailureTypes表
2. 执行迁移，完成所有外键修改等必要的结构变更
3. 再将managed属性改回True，删除旧的FailureTypes模型后重新生成迁移，此时就不会出现重复建表的报错。

内容的提问来源于stack exchange，提问作者Anonymous Programmer