虚拟场的南移答案

【问题标题】：South migration for dummy fields虚拟场的南移
【发布时间】：2011-10-18 04:22:24
【问题描述】：

我们有一个带有自定义 Django 字段的虚拟 Python 模块 (fields.py)，它根据配置的数据库加载实际实现：

if settings.DATABASES['default']['ENGINE'].find('postgresql') != -1:
  from fields_postgresql import *
else:
  from fields_dummy import *

这样做的原因是我们正在使用 PostgreSQL ip4r 扩展，它允许对包含 IP 值的字段进行良好（和快速）的工作。但是我们也有其他数据库的虚拟实现（在 Python 代码中），因此开发也可以在 SQLite 中完成。因此，如果您使用的是 PostgreSQL，则这些字段会与使用 ip4r 索引的字段一起备份，如果您使用的是其他数据库系统，则这些字段是常规字段。

问题是如何在这些领域使用南迁移。问题是add_introspection_rules 发现了fields_postgresql 和fields_dummy，所以这会泄露给迁移。如果您想在使用 PostgreSQL 的安装上应用使用 SQLite 进行的迁移，这就是稍后的问题。

如何让 South 相信这只是 fields 模块，与运行哪个具体实现迁移无关。

【问题讨论】：

我的回答有帮助吗？如果是，请接受。如果没有，很高兴听到一些批评/看到更好的解决方案。
不，抱歉。它没有用。仅仅忽略该领域是不够的，该领域必须在迁移中。 Just South 应该认为这两种实现是平等的。
好的，您是否尝试根据当前使用的数据库自定义add_introspection_rules 加载？
我没有找到用add_introspection_rules影响模块名称的方法。
是的，我同意这不是一个好主意。我可能会放弃对 SQLite 的支持。但它对开发很方便。

标签： python django django-south

【解决方案1】：

放弃对 SQLite 的支持。

你是对的，如果你不是在手机上运行你的开发环境，仅仅为了不安装 Postgre 而维护你自己的基于 South 的迁移脚本可能不值得麻烦。

Postgre 安装与维护自定义迁移代码是一次性操作，而不是连续且可能耗时的过程（因为您可能必须修改自定义迁移代码才能与较新的 South 版本同步）。

【讨论】：

确实如此。但我希望我的 Django 应用程序也能被其他人使用。拥有一种简单的方法来测试我的应用程序是采用它的重要一步。并且不需要 PostgreSQL 对此很重要。所以我的应用程序不仅在内部使用，也仅供我们的开发人员使用，但我们希望它能够被广泛使用。
@Mitar，在接下来的几天里，我将尝试弄清楚如何在不放弃对其他数据库的支持的情况下解决这个问题。
@Mitar，大多数外部开发人员可能不需要迁移您的模型这一事实如何？核心功能是否需要在用户模型中使用此字段？
是的，必填字段。确实，迁移可能不是必需的，但是一旦你将它们放在适当的位置，为 SQLite 关闭它们将是愚蠢的。 ;-) 但是，是的，这是另一种选择。