django和south迁移有冲突(0007_two ...和0007_one)如何解决?

发布于 2024-08-05 08:24:55 字数 840 浏览 3 评论 0原文

我想在 django 项目中使用 South 作为迁移工具,但在多用户场景中使用 South 时遇到问题:

两个开发人员在不同的计算机上同时工作,

  • 在第一台 PC 上创建两个具有相同编号的迁移:0007_extend_lizard.py

  • 在第二台 PC 上:0007_swap_name_adopter.py

在这种情况下,我可以运行 ./manage migrate --merge./manage migrate 0006 (回滚)并再次运行< /strong> ./管理迁移。但是当我想在 models.py 中添加新字段并运行 ./manage startmigration Southdemo --auto 时,South 会得到 models = {}来自上次迁移的元数据,并且它缺少第一次迁移的信息。其结果是创建迁移 0008,并从第一个 0007 再次创建(!!!)更改。

解决此问题的最佳方法是什么?

目前我正在考虑两种选择:

  • 手动将 0007 迁移合并到一个文件中,然后迁移(但必须有人执行“回滚”)

  • 手动将缺少的 models = {} 元移动到最后的 0007 迁移,然后 0008 中的下一个 --auto 将完美工作。

什么是更好的选择?还是我还缺少其他东西?

I want to use south in my django project as migration tool, but I have problem with using south in multiuser scenario:

Two devs working concurrently on different machines create two migrations with same number

  • on first PC: 0007_extend_lizard.py

  • on second PC: 0007_swap_name_adopter.py

In this case I can run ./manage migrate --merge or ./manage migrate 0006 (rollback) and run again ./manage migrate. BUT when I want add new field in models.py and run ./manage startmigration southdemo --auto, then south gets models = {} meta data from the last migration, and it has have missing info from the first migration. The result of this is creating migration 0008 with creating again (!!!) changes from first 0007.

What's the best way to solve this problem?

Currently I'm thinking about two options:

  • Manually merge both 0007 migration in one file and then migrate (but some one must execute "rollback")

  • Manually move missing models = {} meta to last 0007 migration and then the next --auto in 0008 will work perfectly.

What is the better option? Or is there something else I'm missing?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

妄想挽回 2024-08-12 08:24:55

在执行migrate --merge或回滚并迁移之后,如果您知道最近的迁移现在具有不准确的冻结模型,我将创建一个新的无操作迁移,以便将冻结的模型是最新的。只需运行 ./manage.py startmigration myapp --empty freeze_noop。现在,您的冻结模型将在您下次想要自动检测真正的迁移时保持最新。

也许创建无操作迁移看起来有点难看,但对我来说,这似乎比您建议的手动历史编辑选项更干净。您可以将无操作迁移视为 DVCS 中的“合并提交”的等效项。

这个问题应该在South 文档的这一部分中提及;我已提交相关问题。 (更新:现在是了。)

After doing the migrate --merge or rollback-and-migrate, if you know that the most recent migration now has inaccurate frozen models, I would just create a new no-op migration for the purposes of bringing the frozen models up to date. Just run ./manage.py startmigration myapp --empty freeze_noop. Now your frozen models will be up-to-date for the next time you want to autodetect a real migration.

Maybe it seems a little ugly to create a no-op migration, but to me this seems cleaner than either of the manual history-editing options you suggested. You can think of the no-op migration as the equivalent of a "merge commit" in a DVCS.

This issue ought to be mentioned in this section of the South docs; I've filed an issue for it. (Update: now it is.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文