将多次南方移民压缩为一次移民
在开发过程中，我创建了许多迁移，经常反复讨论我想如何实现某些东西。
现在是时候将其投入生产了，但是在原始数据库上重播所有迁移时出现错误。
我最终执行了以下操作以使其正常工作。
python manage.py syncdb --all
python manage.py migrate --fake
但这不适用于我创建的数据迁移。
经过进一步思考，我决定当我准备好将其标记为发布版本时，将所有迁移压缩为一个。
我该怎么做？如果不可能/不推荐，那么首选方法是什么？
During development I created many migrations, often going back and forth about how I wanted to implement something.
Now it is time to push it to production, but I am getting errors when replaying all the migrations on the virgin database.
I ended up doing the following to get it to work.
python manage.py syncdb --all
python manage.py migrate --fake
But that will not apply a data migration that I created.
Upon further thinking, I decided that I wanted to squash all my migrations into just one, when I am ready to tag this as a release version.
How can I do this? If it is not possible/recommended, then what is the prefered method?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是有可能的，而且我自己也做过几次。基本上有两种方法：
1）这是迄今为止最简单且首选的方法。简而言之，将开发数据库回滚到要包含在“squash”中的第一个迁移之前，然后删除该迁移之后的所有迁移。最后，重新运行 schemamigration 管理命令。您最终将在一个文件中获得所有必要的迁移。
2）如果由于某种原因你不能做到#1，它在技术上仍然是可能的，但过程会更加严格。将每次迁移的前向和后向方法的内容逐字复制并粘贴到一个迁移文件（编号最小的文件）中。这部分很简单，但是您还必须对文件底部的冻结模型进行手动修改。我发现最好的方法就是尝试运行这个新的迁移。您可能会收到有关某某模型没有某某属性的错误。这是将该字段添加到冻结模型的信号。当迁移运行没有错误时，您就成功了。
注意：请记住，当您删除这些旧的迁移文件时，请根据您正在使用的任何版本控制系统来删除它们。换句话说，使用
git rm或svn rm等。如果您最终在版本中标记了这些旧迁移，您将破坏您的生产实例。就我而言，在准备好发布更改之前，我从不提交迁移。如果丢失迁移，您始终可以重新生成迁移。It's possible, and I've done it myself a few times. You basically have two methods:
1) This is by far the easiest and preferred method. Simply, rollback your dev database to right before the first migration you want to include in the "squash", then delete all the migrations from that one on. Finally, re-run the schemamigration management command. You'll end up with all the migrations necessary all in one file.
2) If for some reason you can't do #1, it's still technically possible, but will be much more exacting of a procedure. Literally copy and paste the contents of the forwards and backwards methods of each migration into one migration file (your lowest numbered one). That part is easy enough, but you'll then have to also make manual modifications to the frozen models at the bottom of the file. I've found the best way is to simply try to run this new migration. You'll likely get errors about such-and-such model has no attribute such-and-such. That's a signal to go add that field to the frozen model. When the migration runs without errors, you're golden.
Note: Remember when you delete those old migration files, delete them with the any versioning system you're using in mind. In other words, use
git rmorsvn rm, etc. If you end up with those old migrations tagging along in your release, you'll bork your production instance. For my part, I never commit migrations until I'm ready to release my changes. You can always regenerate the migration if you lose it.django manage.py中有一个专门用于此目的的命令。如果您使用迁移作为固定装置，如果您不希望压缩固定装置，则可能需要修改某些迁移中的依赖项属性。
如果您没有固定装置并且只想压缩所有迁移，您可以运行：
其中 app_name 是您的应用程序的名称，0001 是您希望压缩到的迁移。
有关更多信息，请参阅上面链接的文档。
There is a command in the django manage.py specifically for this. If you are using Migrations as fixtures you might need to fiddle with the dependencies attribute in some of the Migrations if you don't wish to squash your fixtures.
If you have no fixtures and simply want to squash all the migrations from you can run:
Where app_name is the name of your app, and 0001 is the migration you wish to squash up to.
See the docs linked above for more information.
您是否尝试过删除所有迁移，然后执行
./manage.py schemamigration myapp --init？请记住，这将破坏任何依赖于这些迁移的内容，因此只有在尚未投入生产时才这样做。
Have you tried deleting all migrations, then doing
./manage.py schemamigration myapp --init?Remember, this will break anything that relies on those migrations, so only do it if you are not in production yet.