与南方的回滚应该如何进行？
让我感到困惑。假设我们有一个向南迁移的 Django 项目。目前，生产项目版本为A，开发版本为B。现在假设版本 B 已安装到生产中：
- 安装新代码
- 运行
./manage.pysyncdb && ./manage.py migrate - 重新启动网络服务器并感到高兴。
下一个假设：版本 B 根本不起作用。它在开发中起作用，但在生产中不起作用，因此必须回滚。这就是我一定遗漏了什么的地方。我看到两种可能性：
- 重新安装旧代码。现在，向南向后迁移是合适的，但是，这是不可能的，因为旧代码不包含返回所需的所有最新迁移。
- 我们首先回滚数据库更改，然后重新安装旧代码。但是，我们如何知道哪个迁移是版本
A的最新迁移？由于一个项目可以轻松计算出几十个应用程序，因此您需要为每个应用程序找出哪个迁移站属于旧版本，然后分别迁移每个应用程序，然后回滚代码并希望得到最好的结果。
在这两种情况下，我都丢失了关键信息，要么是第一种情况下的迁移代码，要么是第二种情况下的“迁移 <-> 版本”关系。我在这里缺少什么？
PS：是的，我知道我可以从备份中恢复数据库，这就是我实际做的。我想知道整个数据库迁移理论如何与回滚相适应。
Color me confused. Let's assume we've got a Django project with South migrations. Currently, production project version is A, version in development B. Now let's suppose version B is installed into production:
- Install new code
- Run
./manage.py syncdb && ./manage.py migrate - Restart web-server and be happy.
Next assumption: version B doesn't work at all. It did in development, but doesn't in production, so it has to be rolled back. And this is where I must be missing something. I see two possibilities:
- Old code in reinstalled. Now, a South back-migration would be appropriate, however, this is not possible, since the old code doesn't contain all the newest migrations needed to go back.
- We first roll-back database changes and then reinstall the old code. However, how do we know which migration is the latest for version
A? Since one project could easily count a couple dozen apps, you'd need to figure out for each of them which migration stand belongs to the old version, then migrate each app separately and then rollback the code and hope for the best.
In both cases, I'm missing crucial information, either migration code in the first case or "migration <-> version" relationship in the second. What am I missing here?
PS: Yes, I know I can restore the database from backup, this is what I actually do. I want to know how this whole database migration theory fits with rollbacks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好的。我猜你正在使用版本控制？此时，确定“A”和“B”的组成部分非常重要。如果我们挥手/猜测我们引用的这个无定形代码块是“A”，而另一个定义模糊的东西我们都标记为“B” - 它是行不通的。
如果您尝试在“B”的位置重新安装“A”，您有两个选择：
1) 从头开始签出并重建“A”（同步和迁移）
2）将“B”滚回到“A”。
1）可能行不通，因为你无法删除数据库中的数据来从无到有地同步它
2）涉及迁移。首先，您应该在“B”而不是“A”中找到迁移。在南部，每个应用程序的所有迁移都进行了编号（0001、0002、0003 等）。因此，假设“B”位于 050，“A”位于 0031。当您签出“B”时，运行 python manage.py migrate appname 0031 这将撤消您对数据库所做的所有更改为“B”制作。然后在版本控制系统中检查“A”（无论“A”只是提交、标签还是分支），
不幸的是，您无法回滚到“A”，然后说“取消迁移您没有的所有内容”。这将是一个更简单的解决方案 - 但随后您需要迁移系统来了解您的版本控制系统，这有点麻烦。
OK. I presume you are working with version control?? That is pretty much crucial at this point to determine what makes up 'A' and 'B'. If we're hand-waving/guessing that this amorpheous blob of code we are referencing is 'A', and this other vaguely defined thing we all label as 'B' - it isn't going to work.
If you are trying to reinstall 'A' in the place of 'B' you have two options:
1) checkout and rebuild 'A' from scratch (sync and migrate)
2) roll 'B' back to 'A'.
1) Likely won't work because you can't afford to kill the data in DB to sync it from nothing
2) Involves migrations. First, you should find the migrations in 'B' and not in 'A'. In south all the migrations for each app are numbered (0001, 0002, 0003, etc). So let's say 'B' is at 050, and 'A' is at 0031. While you have 'B' checked out, run
python manage.py migrate appname 0031That will undo all the DB changes you made for 'B'. Then in your version control system you checkout 'A' (whether 'A' is just a commit or a tag or a branch)Unfortunately you can't rollback to 'A' and then say "unmigrate everything you don't have". That would be an easier solution - but then you'd need you migration system to know about your version control system, and that is a bit hairy.
不确定这是否适合您的情况，但在将代码移回版本“A”之前，您是否不能在生产环境中运行向后迁移？这样你的数据库就可以恢复到你执行syncdb之前的任何迁移，然后你将代码更改回版本A，然后你就回到了开始的地方。
Not sure if this was an option in your case but couldn't you have run the backwards migration in production before you moved your code back to version 'A'? This way your db gets back to whichever migration was there before you did your syncdb and then you change your code back to version A and you're right back to where you started.