0

我刚刚继承了一个用于维护和持续开发的 Django 项目。虽然我是一个相当精通的程序员（也是 Python），但我几乎没有使用 Django 的经验，因此我需要对我的想法进行一些理智的检查；）

当前的问题是：项目包含一个自定义install.sh文件，它做了三件事：

  1. 创建一些非模型数据库并通过 SQL 导入初始数据
  2. 使用导入夹具manage.py
  3. 通常的migrate.py syncdb和migrate.py migrate。

（install.sh还包含一些逻辑来实现半生不熟的south依赖管理，我用原生的代替）

我的想法如下：

  1. 为每个非模型数据库表生成模型（manage.py inspectdb首先，在应用程序中拆分）。
  2. 将所有非south模型转换为south
  3. 将初始 SQL 数据转换为south夹具
  4. 将数据库备份例程转换为manage.py dumpdata（并恢复到manage.py loaddata固定装置）。
  5. 不再使用原始 SQL

现在简单的问题是：这个计划是否明智？有哪些替代方案？

4

2 回答 2

1

如果您追求的是纯粹的非实际 SQL 路线，那么对我来说这听起来足够理智。

两个小点：

  • 3) 中的灯具实际上是 Django 灯具，而不是 South 灯具。
  • 使用 dumpdata 创建 JSON/XML Django 固定装置然后恢复它们并非没有风险。由于循环依赖等原因，某些 django.contrib 应用程序（以及许多其他非 contrib 应用程序）可能会由于 FK 冲突等而导致加载数据痛苦。因此，我建议转储到 SQL 以及固定装置。如果您在阳光下度假时服务器发生爆炸等情况，非 Djangonaut 可以更快地恢复原始 SQL 转储
于 2010-08-24T08:55:32.113 回答
0

为每个非模型数据库表生成模型（首先是 manage.py inspectdb，然后在应用程序中拆分）。

听起来不错。不过，您可能希望在需要使用的基础上继续进行。立即从您需要的人开始。

将所有非南方模型转换为南方

我不太明白非南方模型是什么。如果您的意思是为所有现有模型（然后可能--fake在迁移期间）生成南迁移，那么是的，这是有道理的。

将初始 SQL 数据转换为南夹具

再一次，什么是南方灯具？

将数据库备份例程转换为manage.py dumpdata（并恢复到manage.py loaddata固定装置）。

我不太确定这个。我见过比manage.py. 特别是如果您有遗留触发器/存储过程等。

不再使用原始 SQL

理论上不错。请记住，您将在某些时候不得不挖掘 SQL。只要您不以此为理由与 SQL 失去联系，或以此为借口不让您的手“弄脏” SQL，那么可以，继续。

于 2010-08-24T08:46:33.507 回答