如何用好Django 中的migration(迁移)功能

Django中又一个有用的功能，叫django Migrations, 中文名是迁移。

迁移是Django最有用的功能之一，但对我个人来说，处理模型更改是一项可怕的任务。尽管阅读了这些文档，但我仍然担心迁移冲突或丢失数据，或者不得不手动修改迁移文件。问题是，迁移是令人敬畏的，有帮助的，一旦你理解了它们，你就不会对上面提到的任何事情有任何问题。

我还没有找到能在一个地方提供解决冲突的所有方法的文章或文档片段，而且因为没有人搜索第二个可以隐藏尸体的Google页面，所以我将尝试对这些问题进行一些解释。主要是，我将尝试解释您在应用程序中的何处可以找到迁移，如何避免迁移冲突，以及有关数据迁移的一些信息。我假设您对Django、Python和GIT有一些经验。

以下是Django文档中关于迁移的简短定义:

迁移是Django传播对模型所做更改(添加字段、删除模型等)的方式。)转换为数据库模式。它们主要是自动设计的，但您需要知道何时进行迁移、何时运行迁移以及可能遇到的常见问题。

无论您选择PostgreSQL、MySQL还是SQLite，都可以仅使用少量命令来管理数据库。我将主要讨论makemovations命令，它负责根据您对模型所做的更改创建新的迁移；migrate命令，它负责应用迁移以及取消应用迁移并列出迁移状态。

我的迁移在哪里？

在项目中，可以找到迁移文件( . )。py文件)在迁移文件夹中。此文件夹必须包含_ _ init _ _。py文件，即使您还没有初始迁移。

在设置文件中定义的每个已安装应用程序中，您将发现该应用程序附带的每个迁移。例如，您可以在... / lib / pythin 2.7 /站点包/ django / contribute /授权/迁移中找到用户迁移。

在数据库中，您可以通过列出django _ moverations表来查找应用了哪些迁移。当您在具有不同迁移的分支之间切换时，这一点非常有用，并且您忘记了迁移的位置。

首先，为什么要在我的项目中保留迁移？

有些人可能会说:为什么GIT不忽略Python / Django项目中的所有迁移，让每个开发人员创建自己的迁移文件？这样我们就可以避免不必要的头痛。这就是撰写本文的原因之一。

在进一步挖掘之前，我要确保每次修改模型时都必须生成迁移，并且必须提交迁移并将其推送到存储库中，以便所有开发人员都具有相同的迁移集。我怎么强调都不过分。

为什么这么重要？假设您的项目中没有迁移。每个团队成员单独在本地生成迁移文件。然后，到了我希望我的项目投入生产的时候了。我部署、创建初始迁移并迁移数据库。过了一段时间，我进行了模型更改并再次部署，因此必须在此生产服务器上进行新的迁移。但是，如果现在我想要第二台生产服务器，会发生什么情况？我部署、创建初始迁移并迁移数据库。现在，我有了第一个生产服务器，有两个迁移，第二个生产服务器，只有一个迁移。这是一个很大的矛盾。我无法再跟踪数据库更改，也无法执行任何回滚。基本上，如果我现在需要任何数据库回滚，我必须处理我的每个生产服务器上的数据库回滚。

因此，请将迁移保留在项目中。您可能会遇到一些(可管理的)冲突，但如果您想要数据库版本化或希望能够回滚数据库，请通过跟踪迁移来简化开发人员的生活。

移徙冲突

假设我们有一个Django项目，一个初始迁移，我们使用GIT。我们使用GIT，因此我们使用分支。我们使用分支，因此在合并分支时可能会发生迁移冲突。当然，团队应该知道谁在做什么，并尽量避免使用相同的模型。当然，团队协作很重要。但不能总是避免迁移冲突。所以，不要像我这么多次做的那样，惊慌失措地丢弃数据库！它们很容易修复，为了做到这一点，我将解释一些简单但非常有用的方法。你可以选择最适合你需要的。如果您需要先复习一些Git，您可以尝试阅读我们的“Git提示和技巧”文章。

我们知道，我们需要对数据库进行初始迁移( Django会将任何模型与初始迁移进行比较，而不是与数据库当前状态进行比较)，我们不会手动修改数据库。

假设我们有一个用户配置文件模型，有两个分支:

branch _ 1，其中一个开发人员向用户配置文件模型添加了“地址”字段，从而具有迁移0003 _ UserProfile _ address

branch _ 2，其中我要向用户配置文件模型中添加一个“年龄”字段，从而具有迁移0003 _ UserProfile _ age . py

我的分支是分支2，我想将分支1合并到分支2中。GIT合并后，我在branch _ 2上有我的迁移，还有来自branch _ 1的0003 _ userprofile _ address . py。这里的问题是，两个迁移都尝试更改相同的模型，并且两个迁移名称都以“0003 _”开头。

有三种可能的解决方案。我个人推荐的前两种解决方案，但我建议您尽可能避免使用第三种解决方案。

数据迁移

迁移必须成为项目一部分的另一个原因是数据迁移。例如，如果需要将多对多关系更改为一对多关系，或者需要将表拆分为两个不同的表，那么我们当然会应用迁移。但数据会发生什么情况？我们仍然需要数据库中当前的所有数据。那么，数据迁移的好处就来了。您编写了一个自定义迁移，几个脚本结合所需的模式来处理数据，然后执行python manage。就这样！您已经在新模式中重构了数据。

数据迁移明确需要依赖关系。此依赖关系引用最新应用的迁移(更确切地说，它的名称)，需要由开发人员设置。但是，如果我们的生产服务器上有不同的迁移集，那么我们需要注意在每个服务器上相应地设置依赖关系。这是乏味的，并且能够避免它使得迁移机制更大。

此外，固定设备和数据迁移之间也存在差异。夹具用于将默认数据加载到数据库中，而数据迁移用于更改数据库本身中的数据。夹具是一个JSON文件，它位于夹具文件夹中，并使用命令python manage . pt laodda myapp /夹具/ my _ fixture . JSON加载。这样，您就有了一组默认填充数据库的对象。另一方面，数据迁移本身就是一种迁移，它位于迁移文件夹中。不使用数据迁移在数据库中添加新条目，只更改数据库中的数据。

结论

迁移是一种非常强大的数据库版本控制机制。在使用Django和数据库时，必须始终考虑使用迁移。

即使您没有编程背景，或者您使用过其他不使用类似机制的框架，也要尝试并了解它们背后的逻辑。它们并不像最初看起来那么复杂，它们引起的所有问题都很容易解决。