虚拟字段向南迁移
我们有一个带有自定义 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 模块，与哪个具体实现迁移一起运行并不重要。
We have a dummy Python module (fields.py) with custom Django fields which loads real implementations based on the database configured:
if settings.DATABASES['default']['ENGINE'].find('postgresql') != -1:
from fields_postgresql import *
else:
from fields_dummy import *
The reason for this is that we are using PostgreSQL ip4r extension which allows nice (and fast) work with fields containing IP values. But we also have dummy implementations (in Python code) for other databases, so that development can be done also in SQLite. So if you are using PostgreSQL those fields are backed up with fields using ip4r indexes and if you are using some other database system those fields are regular fields.
The problem is how to use South migrations on such fields. The problem is that add_introspection_rules discovers fields_postgresql and fields_dummy so this leaks to migrations. This is the problem later on if you want to apply a migration made with SQLite on an installation with PostgreSQL.
How it would be possible to convince South that this is all just fields module and it does not matter which concrete implementation migrations are run with.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
放弃对 SQLite 的支持。
你是对的，如果你不是在手机上运行你的开发环境，仅仅为了不安装 Postgre 而维护你自己的基于南方的迁移脚本可能不值得。
Postgre 安装与维护自定义迁移代码相比是一次性操作，而不是连续且可能耗时的过程（因为您可能需要修改自定义迁移代码才能与较新的 South 版本同步）。
Drop support for SQLite.
You are right, if you aren't running your development environment on a mobile phone, maintaining your very own South-based migration script just in a sake of not installing Postgre probably isn't worth the hassle.
Postgre installation versus maintaining custom migration code is a one-time action versus continuous and potentially time-consuming procedure (since you will potentially have to modify your custom migration code in order to be in sync with newer South releases).