9

我犯了在同一个 Django 应用程序中创建太多模型的愚蠢错误，现在我想将它分成 3 个不同的模型。问题是：两个客户的站点中已经有生产数据，所以我需要仔细计划要完成的任何模式/数据迁移（我正在使用 django-south）。我不确定如何进行，任何建议将不胜感激。

（如果有任何相关性，我在 Ubuntu 服务器 12.4 LTS 上使用 PostgreSQL）

我考虑过使用db.rename_table，但无法弄清楚如何正确更新这些模型的外键（从旧到新） - 在数据库级别无关紧要（因为表重命名已经涵盖了），但在 ORM 级别并非如此.

更新：经过思考，并在programmmers.SE上提出这个问题后，我决定保持简单，不用担心产品主要版本之间的迁移。短期内，我将只使用db.rename_table匹配新名称，同时也db_table按照 Daniel Roseman 的建议使用，同时将模型保留在旧应用程序中。升级到主要版本时，我切换到新应用程序并完全放弃所有迁移（因此新版本的全新安装将“按原样”创建数据库，而不是经历所有历史迁移）。

4

3 回答 3

15

我根本不明白您为什么需要任何数据迁移。

只需将模型移动到新应用程序中，并db_table在内部 Meta 类中添加一个设置以指向旧表名。

于 2012-07-16T17:31:35.417 回答
3

我最近在较小的范围内做了类似的事情，这是我的过程：

  1. 创建新的应用程序和相应的模型
  2. 更新视图以使用新模型
  3. 更新单元/系统测试以确保没有损坏（重要！）
  4. 编写基于旧模型填充新模型的管理命令
  5. 部署代码
  6. 为新模型运行迁移
  7. 运行管理命令脚本以更新新模型
  8. 将旧应用程序保留 1-2 周，当您认为一切都很好时，将其删除。

我没有使用数据迁移的原因：

  1. 不熟悉——觉得任务太重要了，不能使用我不熟悉的流程
  2. 使用 Python 代码移动数据比使用 South magic 更舒服
  3. 遇到依赖关系的南迁移问题。不想通过数据迁移使迁移进一步复杂化。由于我不熟悉数据迁移的机制，这可能是一个错误的假设
  4. 也许作为第 3 点的偏见，我说服自己将 South 纯粹用作模式管理工具是“正确”的做法。数据的创建/更新应该在 Django 层中使用夹具或自定义管理命令完成
于 2012-07-16T06:11:16.923 回答
2

我能想到的最简单的解决方案：

  1. 创建SchemaMigration将旧应用程序中模型的每个外键的类型更改为原始类型（包括其内部的类型）；
  2. 正常创建新应用及其模型；
  3. 将旧表的数据迁移到新表；
  4. 创建另一个SchemaMigration，将每个原始类型再次更改为外键，现在指向新表；
  5. 从设置中删除旧应用程序并删除其表。

费力，是的，但会成功的。不过，我希望有更好的解决方案。

于 2012-07-16T04:36:45.830 回答