姜戈移民，假的，假的首字母解释

我已经使用 Django 两年了，有一个特性我一直害怕使用: < strong > 伪造迁移 。

我几乎到处都找过了，我能得到的最多的信息来自 文件，它说:

假的

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

这是为高级用户设计的，用于操作当前 如果它们手动应用更改，则直接进行迁移状态; 警告说，使用假冒伪劣产品有将移民国家 表进入一个状态，将需要手动恢复，使 迁移运行正确。

名字缩写是假的

允许 Django 跳过应用程序的初始迁移，如果所有数据库 表，其中包含由所有 CreateModel 创建的所有模型的名称 该迁移中的操作已经存在。此选项的目的是 对数据库进行第一次迁移时使用 预先存在迁移的使用。但是，这个选项不检查 除了匹配表名之外，还可以匹配数据库模式 只有当您确信您现有的模式是安全的时候才可以使用 与初始迁移中记录的内容相匹配。

我大致了解了为什么要使用这个特性。但是，我不明白为什么说这是 仅供高级用户使用

谁能解释一下幕后发生了什么以及为什么需要人工恢复。

注意:

我不是在寻找伪造迁移时运行的准确的原始 SQL 查询。我只是在寻找幕后发生了什么的大概概念，也许还有一个例子来说明为什么要伪造迁移 将导致 makemigrations无法正常工作的状态。

119329 次浏览
小开
最佳答案

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

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.

EDIT: 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

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.)

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

EDIT: 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.


提交答案