Django migrate --fake 和 --fake-initial 解释 [英] Django migrate --fake and --fake-initial explained

问题描述

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

I've been a user of Django for about 2 years now and there is a feature I have always been afraid of using : faking migrations.

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

I've looked pretty much everywhere and the most information I can get is from the documentation where it states that:

--假

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

Tells Django to mark the migrations as having been applied or unapplied, but without actually running the SQL to change your database schema.

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

This is intended for advanced users to manipulate the current migration state directly if they’re manually applying changes; be warned that using --fake runs the risk of putting the migration state table into a state where manual recovery will be needed to make migrations run correctly.

--fake-initial

如果所有数据库都允许 Django 跳过应用程序的初始迁移包含所有 CreateModel 创建的所有模型名称的表该迁移中的操作已经存在.此选项旨在用于首次针对数据库运行迁移时使用预先存在迁移的使用.但是，此选项不检查用于匹配数据库模式而不是匹配表名等只有在您确信现有架构的情况下才能安全使用与初始迁移中记录的内容相匹配.

Allows Django to skip an app’s initial migration if all database tables with the names of all models created by all CreateModel operations in that migration already exist. This option is intended for use when first running migrations against a database that preexisted the use of migrations. This option does not, however, check for matching database schema beyond matching table names and so is only safe to use if you are confident that your existing schema matches what is recorded in your initial migration.

我大致了解了为什么要使用此功能.但是，我不明白它说这是仅供高级用户使用的部分.

I get the general idea and why one would want to use this feature. But, I don't understand the part where it says that this is intended for advanced users only.

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

Can someone explain what is happening behind the scene and why manual recovery would be needed.

注意

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

I'm not looking for the exact raw SQL queries that runs when faking a migration. I'm only looking for a general idea of what is happening behind the scene and maybe an example of why faking a migration would result in a state where makemigrations would not be working correctly.

推荐答案

如果需要合并两个模型相似的分支或者在两者之间切换，则涉及到一个类似于源代码(git)中的合并冲突的数据库问题他们.没有人故意喜欢它.

It is related to a database problem similar to a merge conflict in a source code (git) if you need to combine two branches with similar models or to switch between them. Nobody likes it intentionally.

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

Imagine that you started to modify an application last week, maybe because you found a bug or you extended the app by a field or table. Today you received an update and you have a problem, because there is a migration that adds a field that is still in your database and you can apply only other parts of that migration. You look at SQL contents of the migration by running

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

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

compare the content with the change made last week and remove or comment out a command that is still applied and can not be repeated. Run all remaining SQL manually. Mark that migration like it would be applied automatically:

./manage migrate --fake some_app 0007_new_migration

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

If you break something, nobody can help you probably, because the migration system will not know the current state of the database more. Therefore do a backup, write notes, use a sandbox and work precisely.

编辑:迁移表django_migrations 是一个简单的迁移列表，列出了在所有应用中应用的迁移.此表中的行应始终与数据库结构处于同步状态.可以通过普通的 migrate 应用迁移.(或通过反向迁移到旧状态未应用，当然通常会丢失一些数据)假迁移仅将更改应用于 django_migrations 表.

The migration table django_migrations is a simple list of migrations applied in all apps. Rows in this table should be always in a synchronized status with the database structure. Migrations can be applied by a normal migrate. (or un-applied by a reverse migration to an older state, usually with some data loss of course) A fake migration applies the change only to the django_migrations table.

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<时进行比较/代码>.在某些表最初未受管理并且以后可以被管理的情况下，这也足够了.(因此也记录了非托管表.)

A migration (file) is a description of incremental change and also information to be possible to evaluate the difference between models.py since the last migration, that is compared when running makemigrations. It is enough also in the case where some tables were un-managed initially and they could become managed later. (therefore unmanaged tables are also recorded.)

一个例子:如何使用 sqlmigrate 和 --fake 来通过迁移修复损坏的数据库(重新创建已删除的表).

An example: how sqlmigrate with --fake could be used to fix a broken database by migrations (to recreate a deleted table).

示例:如果您决定删除某个应用程序的表并通过 migrate 重新创建它们(请注意并查看下面我的评论)，您可能还想要首先通过伪迁移名称零"重置该应用程序的所有迁移，包括初始迁移.
./manage migrate --fake some_app zero.

Example: If you decided to delete tables of some application and to create them again by migrate (be warned and see my comment below), you probably also want to reset all migrations of that application first, including the initial migration, by a pseudo-migration name "zero".
./manage migrate --fake some_app zero.

这篇关于Django migrate --fake 和 --fake-initial 解释的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！