如果你需要将两个具有相似模型的分支合并或在它们之间进行切换,则这与数据库问题类似,类似于源代码(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
如果你破坏了某些内容,则没人会帮助你,因为迁移系统将无法进一步了解数据库的当前状态。因此,请进行备份,写笔记,使用沙箱并精确地工作。
编辑:迁移表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
。在某些表最初未被管理并且以后可以被管理的情况下也足够了。(因此也记录了非托管表。)
编辑:一个示例:如何sqlmigrate使用–fake可以通过迁移来修复损坏的数据库(重新创建已删除的表)。
编辑:示例:如果你决定删除某个应用程序的表,然后通过创建它们migrate,你可能还想通过伪迁移名称“ 零 ” 首先重置该应用程序的所有迁移,包括初始迁移。 ./manage migrate –fake some_app zero。