Django migrate --fake 和 --fake-initial 解释

我使用 Django 已经大约两年了，有一个功能我一直害怕使用：伪造迁移.

我几乎到处都查过，我能得到的最多信息来自文档其中指出：

--fake

告诉 Django 将迁移标记为已应用或 未应用，但没有实际运行 SQL 来更改您的 数据库架构。

这是为了让高级用户操纵当前 如果他们手动应用更改，则直接迁移状态；是 警告使用 --fake 存在放置迁移状态的风险 表进入需要手动恢复的状态 迁移正确运行。

--假首字母

如果所有数据库都允许 Django 跳过应用程序的初始迁移 包含所有 CreateModel 创建的所有模型名称的表 该迁移中的操作已经存在。该选项的目的是 首次针对数据库运行迁移时使用 迁移的使用是预先存在的。但是，此选项不会检查 用于匹配数据库模式超出匹配表名的范围，所以 仅当您确信现有架构时才可以安全使用 与您初始迁移中记录的内容匹配。

我了解了总体思路以及为什么人们想要使用此功能。但是，我不明白它说的那部分仅适用于高级用户。

有人可以解释一下幕后发生了什么以及为什么需要手动恢复。

NOTE

我并不是在寻找伪造迁移时运行的确切原始 SQL 查询。我只是在寻找幕后发生的事情的一般概念，也许还有一个为什么要伪造迁移的例子 会导致这样的状态makemigrations将无法正常工作。

如果您需要合并两个具有相似模型的分支或在它们之间进行切换，则与源代码（git）中的合并冲突类似的数据库问题有关。没有人故意喜欢它。

想象一下，您上周开始修改一个应用程序，可能是因为您发现了一个错误，或者您通过字段或表扩展了应用程序。今天您收到了更新，但遇到了问题，因为有一个迁移添加了仍在数据库中的字段，并且您只能应用该迁移的其他部分。您可以通过运行来查看迁移的 SQL 内容

./manage sqlmigrate some_app 0007_new_migration >customized-some_app-0007_new_migration.sql

将内容与上周所做的更改进行比较，并删除或注释掉仍然应用且无法重复的命令。手动运行所有剩余的 SQL。将迁移标记为自动应用：

./manage migrate --fake some_app 0007_new_migration

如果你破坏了某些东西，可能没有人可以帮助你，因为迁移系统不会更多地了解数据库的当前状态。因此，做好备份、写笔记、使用沙箱并精确工作。

EDIT:迁移表django_migrations是所有应用程序中应用的迁移的简单列表。该表中的行应始终处于与数据库结构同步的状态。迁移可以通过正常应用migrate。 （或者通过反向迁移到旧状态而未应用，当然通常会丢失一些数据）假迁移仅将更改应用于 django_migrations 表。

me => select * from django_migrations;
 id | app      |          name           |            applied            
----+----------+-------------------------+-------------------------------
  1 | some_app | 0001_initial            | 2017-10-16 06:11:07.31249+02
  2 | some_app | 0002_auto_20171016_1905 | 2017-10-17 02:05:48.979295+02

迁移（文件）是增量更改的描述，也是可评估之间差异的信息models.py自上次迁移以来，运行时进行比较makemigrations。在某些表最初不受管理并且稍后可以受管理的情况下，这也足够了。 （因此非托管表也会被记录。）

EDIT:一个例子：如何sqlmigrate with --fake可以用来通过迁移修复损坏的数据库（重新创建已删除的表）。

EDIT:示例：如果您决定删除某个应用程序的表并通过以下方式重新创建它们migrate（请注意，请参阅下面的评论），您可能还想首先通过伪迁移名称重置该应用程序的所有迁移，包括初始迁移”zero".
./manage migrate --fake some_app zero.