Django迁移--fake和--fake-initial解释

Question

我已经成为Django的用户大约2年了,并且有一个我一直害怕使用的功能:伪造迁移.

我几乎到处都看了,我能得到的最多信息来自文档,其中说明:

- 假

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

这适用于高级用户在手动应用更改时直接操作当前迁移状态; 请注意,使用--fake会冒着将迁移状态表置于需要手动恢复以使迁移正确运行的状态的风险.

--fake-初始

如果所有具有该迁移中所有CreateModel操作创建的模型名称的数据库表已存在,则允许Django跳过应用程序的初始迁移.此选项适用于首次针对预先存在使用迁移的数据库运行迁移时使用.但是,此选项不会检查匹配的表名称之外的匹配数据库模式,因此只有在您确信现有模式与初始迁移中记录的模式匹配时才可以安全使用.

我得到了一般的想法以及为什么人们想要使用这个功能.但是,我不明白它所说的部分仅适用于高级用户.

有人可以解释幕后发生的事情以及为什么需要手动恢复.

注意

我不是在寻找伪造迁移时运行的确切原始SQL查询.我只是在寻找关于场景背后发生的事情的一般概念,也许是为什么伪造迁移会导致状态makemigrations无法正常工作的一个例子.

Answer 1

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

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

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

./manage migrate --fake some_app 0007_new_migration

如果你破坏了某些东西,没有人可能会帮助你,你或迁移系统都不知道数据库的当前状态.因此备份,写笔记,使用沙箱并精确地工作.

编辑迁移表django_migrations是所有应用程序中应用迁移的简单列表.此表中的行应始终与数据库结构处于同步状态.可以通过正常迁移来应用迁移.(或通过反向迁移到旧状态而不应用,当然通常会丢失一些数据)虚假迁移仅将更改应用于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

迁移(文件)是增量更改的描述,可以在运行时评估自上次迁移以来模型中的差异migrate.在最初未管理某些表并且稍后可以管理它们的情况下也足够了.

编辑一个示例如何models.py和makemigrations可以用于通过迁移修复损坏的数据库(重新创建已删除的表).