避免 InconsistentMigrationHistory 在迁移中显式插入

Question

我对迁移的顺序有一点问题。事实上，在我的数据库中有一个“产品”模型，它的迁移是历史列表中的第一个，称为 001_products。在此迁移之后，将执行其他在同一个表中进行插入的操作（应用程序的基本操作所必需的一些插入），称为迁移002_inserts_products。

修改“Products”模型时出现问题，称之为003_modify_products迁移。在插入之后应用迁移并导致测试失败（生成测试数据库的测试执行所有迁移），遵循以下顺序：

1. 001_products
2. 002_inserts_products
3. 003_modify_products

然后解决方案是添加对在“产品”中进行插入的迁移的依赖关系，以适应随后修改该表的迁移。即使 002_inserts_products 依赖于 003_modify_products。

但是，这在测试和本地工作（已经应用“产品”中的修改）在生产中不起作用，因为尚未应用的迁移是修改“产品“型号”。

即制作中的全景图为：

1. [X] 001_products
2. [X] 002_inserts_products
3. [ ] 003_modify_products

尝试进行新迁移时，出现的错误是：

django.db.migrations.exceptions.InconsistentMigrationHistory：迁移 002_inserts_products 在其依赖 003_modify_products 对数据库“默认”之前应用。

问题是如何将迁移设置为在测试和生产中都可以工作（也就是说，在之前的迁移已经完成的情况下）？

Answer 1

不幸的是，您正试图通过修改较旧的迁移使其依赖于较新的迁移来解决您自己创建的问题的解决方案，从而避免测试失败。

正确的解决方案是执行以下操作：

1. 移除002_inserts_products对003_modify_products的依赖，恢复原状。
2. 添加004_update_products 以更新通过002_insert_products 插入的任何产品，以便它们与003_modify_products 中的表修改一起使用。
3. 更新您的测试以适应 003_modify_products 中所做的更改。

更改已运行迁移的预期顺序绝不是一个好主意，因为虽然它可能在您的本地环境中工作，但当您部署到没有这些迁移的服务器时，它很可能会崩溃已经跑了。

另外请记住，测试失败并不总是表明您做错了什么——测试，尤其是数据库测试，不一定是面向未来的。由于架构更改而必须更新测试是完全正常的。