Home/ Questions/Q 6805231
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T19:33:42+00:00

We have a dummy Python module ( fields.py ) with custom Django fields which

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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).

    • 0