Django文档说我们可以在压缩之后删除迁移:
您应该提交此迁移但保留旧迁移;该 新迁移将用于新安装。一旦你确定了所有 代码库的实例已应用您压缩的迁移, 你可以删除它们。
这里,删除是否意味着只删除迁移文件或django_migrations表中的条目?
以下是一些背景知识:我只有开发机器,所以只有一个代码库。在压缩我已经应用的一些迁移之后,我删除了文件和数据库条目。通过进行迁移测试是否正常,但没有找到任何内容。所以,一切看起来都不错。第二天,我不得不改变一些事情,并进行迁移。当我尝试迁移时,它也尝试应用压扁的迁移(在被压扁之前逐部分应用)。所以,我必须返回并重新创建django_migrations表中的条目。所以,似乎我必须保留数据库条目。我试图确保在我再次陷入困境之前,先了解为什么它看起来很好,然后尝试应用压扁的迁移。
答案 0 :(得分:4)
压缩的迁移永远不会标记为已应用,将在1.8.3中修复(请参阅#24628)。
删除旧迁移的步骤如下:
replaces
属性。./manage.py migrate <app_label> <squashed_migration> --fake
。当1.8.3到达时,最后一步是不必要的。
答案 1 :(得分:2)
自问题发布以来,转换压缩迁移变得更加容易。我发布了一个small sample project,其中展示了如何使用循环依赖关系压缩迁移,还展示了在所有安装迁移到压缩点之后如何将压缩迁移转换为常规迁移。
正如Django documentation所说:
然后,您必须通过以下方式将压扁的迁移转换为正常迁移:
- 删除它替换的所有迁移文件。
- 更新依赖于已删除迁移的所有迁移,以取决于压缩的迁移。
- 删除了压缩迁移的Migration类中的replaceces属性(这就是Django告诉它是一个被压扁的迁移的方式)。
答案 2 :(得分:0)
我无论如何都不是专家,但我只是压制了我的迁移,最后做了以下事情:
执行此查询以删除旧迁移(压扁)
DELETE FROM south_migrationhistory;
运行此管理命令以删除幻影迁移
./manage.py migrate --fake --delete-ghost-migrations
Django 1.7也有squashmigrations