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

问题描述

我已经使用Django大约两年了，我一直不敢使用的功能： 伪造迁移 。

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.

这是供高级用户在手动应用更改时直接操纵当前的
迁移状态的； be
警告说，使用--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.

-伪初始

如果所有数据库
表具有该迁移中所有CreateModel
操作创建的所有模型的名称，则允许Django跳过应用程序的初始迁移。此选项供
使用，当
首次运行迁移到已预先使用迁移的数据库时。但是，此选项不会检查
是否匹配表名称之外的匹配数据库架构，因此只有确信您现有的架构
匹配初始表中记录的内容时，
才可以安全使用

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.

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

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 是所有应用中应用的迁移的简单列表。该表中的行应始终与数据库结构处于同步状态。可以通过普通的迁移来应用迁移。 （或未应用到较旧状态的反向迁移，通常当然会丢失一些数据）虚假迁移仅将更改应用于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 与code>-fake 可用于通过迁移修复损坏的数据库（重新创建已删除的表）。

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

编辑：示例：如果您决定删除某些应用程序的表并通过 migrate重新创建它们（警告并在下面查看我的评论），您可能还想先通过伪迁移名称 零。

。/管理迁移--fake some_app零。

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的--fake和--fake-initial解释的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！