Question

我正在删除项目中的一些死代码，我有机会删除自我们启动项目以来我们一直在使用的第三方应用程序的依赖项。我们的一个模型对第三方应用程序中的模型有一个ForeignKey，并且在尝试在项目的新实例上应用迁移时遇到了麻烦。

示例模型：

from django.db import models
from thirdparty.models import ThirdPartyModel

class MyModel(models.Model):
    fk = models.ForeignKey(ThirdPartyModel)

South检测到删除MyModel.fk并成功创建迁移。应用迁移并将其回滚也可以。我现在可以从thirdparty删除INSTALLED_APPS并提交更改（新迁移和settings.py）。

当我在另一台机器上克隆存储库时，麻烦就开始了。 ./manage.py syncdb按预期运行并创建所有不由South管理的表，但./manage.py migrate myapp在为MyModel的（早期版本）创建表时失败，因为thirdparty_thirdpartymodel的外键无法创建（正如预期的那样，因为thirdparty不再位于INSTALLED_APPS中，因此没有创建任何表格。）

是否有标准方法来处理删除外部依赖项？这是重置迁移的适当时机吗？

Answer 1

这是一个老问题，但它仍然有效，甚至独立于南方，也是Django Migrations的一个问题。

您应该注意迁移文件的分离方式可以伪造依赖于不存在的应用程序的迁移（从INSTALLED_APPS中删除）。这样，您可以通过伪造这些迁移来创建新安装，并在现有安装上实际运行这些迁移。

当然，如果您有可能重新开始（如完全重新启动），您可以擦除数据库，删除所有现有的迁移文件，只需创建全新的迁移。所有其他开发人员也必须删除他们的数据库。

如果您有现有的生产数据并且仍想从头开始，那么如何传输数据有不同的可能性。哪种方式最好取决于数据量，结构变化程度等等：

普通SQL（在运行新迁移之后，通过将数据从旧表传输到新表并删除表和外键等来手动更改数据库）。
fixtures（通过旧系统中的Django转储数据并更改JSON以适应新结构）
旧系统和新系统的两个并行安装，并通过Django / Python脚本传输（比普通SQL慢，但您可以使用Django模型逻辑，以更舒适的方式应用验证检查，转换等）。 / LI>

当然，不要在制作中这样做，而是在其他地方做，只需应用结果。

将ForeignKey删除到第三方模型后迁移

1 个答案: