python - 使用必需的ForeignKey引用在Django(1.8)应用程序之间移动模型

Question

这是对这个问题的扩展:How to move a model between two Django apps (Django 1.7)

我需要将一堆模型从old_app移到new_app。最好的答案似乎是Ozan's，但是使用必需的外键引用，事情会变得有些棘手。 @halfnibble在对Ozan的回答的注释中提出了一种解决方案，但是我仍然无法确定确切的步骤顺序(例如，何时将模型复制到new_app，何时从old_app删除模型，迁移将坐下来在old_app.migrations与new_app.migrations等中)

任何帮助深表感谢!

Answer 1

在应用之间迁移模型。

简短的答案是，不要这样做!

但是，这个答案在现实生活中的项目和生产数据库中很少起作用。因此，我创建了一个sample GitHub repo来演示这个相当复杂的过程。

我正在使用MySQL。 (不，这些不是我的真实凭证)。

问题

我使用的示例是带有 cars 应用程序的工厂项目，该应用程序最初具有Car模型和Tires模型。

factory
  |_ cars
    |_ Car
    |_ Tires

Car模型与 Tires具有ForeignKey关系。 (同样，您可以通过汽车模型指定轮胎)。

但是，我们很快意识到 Tires将成为具有自己的 View 等的大型模型，因此我们希望在自己的应用程序中使用它。因此，所需的结构为:

factory
  |_ cars
    |_ Car
  |_ tires
    |_ Tires

并且我们需要保持 Car和 Tires之间的ForeignKey关系，因为太多依赖于保留数据。

解决方案

步骤1. 设置具有不良设计的初始应用程序。

浏览 step 1.的代码

步骤2。创建一个管理界面，并添加一堆包含ForeignKey关系的数据。

查看 step 2.

步骤3. 决定将 Tires模型移至其自己的应用程序。认真地将代码粘贴到新的轮胎应用中。确保更新 Car模型以指向新的 tires.Tires模型。

然后运行 ./manage.py makemigrations并将数据库备份到某个地方(以防万一这失败了)。

最后，运行 ./manage.py migrate并查看doom的错误消息，

django.db.utils.IntegrityError:(1217，“无法删除或更新父行:外键约束失败”)

在 step 3.中到目前为止查看代码和迁移

步骤4. 棘手的部分。自动生成的迁移无法看到您只是将模型复制到其他应用程序。因此，我们必须做一些事情来纠正这一问题。

您可以按照以下步骤进行操作，并在 step 4.中查看带有注释的最终迁移，我对此进行了测试以验证其是否有效。

首先，我们将研究 cars。您必须进行新的空迁移。实际上，此迁移需要在最近创建的迁移(执行失败的迁移)之前运行。因此，我对重新创建的迁移进行了重新编号，并更改了相关性以首先运行我的自定义迁移，然后运行 cars应用程序的最后一个自动生成的迁移。

您可以使用以下方法创建一个空迁移:

./manage.py makemigrations --empty cars

步骤4.a。 进行自定义old_app迁移。

在第一个自定义迁移中，我将仅执行“database_operations”迁移。 Django为您提供了拆分“状态”和“数据库”操作的选项。您可以通过查看 code here来了解如何完成此操作。

我第一步的目标是将数据库表从 oldapp_model重命名为 newapp_model，而不会弄乱Django的状态。您必须确定Django将根据应用程序名称和模型名称为数据库表命名的方式。

现在，您可以修改初始 tires迁移了。

步骤4.b。 修改new_app初始迁移

操作很好，但是我们只想修改“状态”，而不是数据库。为什么？因为我们保留了 cars应用程序中的数据库表。另外，您需要确保先前进行的自定义迁移是该迁移的依赖项。参见轮胎 migration file。

因此，现在我们在数据库中将 cars.Tires重命名为 tires.Tires，并更改了Django状态以识别 tires.Tires表。

步骤4.c。 修改old_app最后一次自动生成的迁移。

回到汽车上，我们需要修改最后一次自动生成的迁移。它应该需要我们的第一个定制汽车迁移和最初的轮胎迁移(我们刚刚修改)。

在这里，我们应该保留 AlterField操作，因为 Car模型指向不同的模型(即使它具有相同的数据)。但是，我们需要删除有关 DeleteModel的迁移行，因为 cars.Tires模型不再存在。它已完全转换为 tires.Tires。查看 this migration。

步骤4.d。 清理old_app中的陈旧模型。

最后但并非最不重要的一点是，您需要在cars应用中进行最终的自定义迁移。在这里，我们将执行“状态”操作，仅删除 cars.Tires模型。它是仅状态的，因为 cars.Tires的数据库表已重命名。此 last migration清除剩余的Django状态。