Running migrations on the non-default database fails

[Gergely Polonkai]

Hello,

I have an application which, due to low usage, used SQLite in production. Now the demand has risen for the app, and SQLite can't really keep up with with all the new users. We decided to move to PostgreSQL.

The DB is now up and running, but to cause as short downtime as possible, I added a new database to settings.py, and tried to run migrations on it:

python manage.py migrate --database postgre

The first few ran fine, but one of them tried to do a RunPython function which should have modified the value of a column that had been removed from the production database in a later migration. At this point migrations failed: it turned out that, despite the --database parameter, RunPython wanted to iterate through the rows of the production database.

Is this a problem/limitation in Django, or should I update my migration functions to use the correct database? If the latter, how do I know which database to use?

Best,
Gergely

[Tim Graham]

I think this bit from the Django 1.8 release notes might help:

* The migration operations RunPython and RunSQL now call the allow_migrate() method of database routers. The router can use the newly introduced app_label and hints arguments to make a routing decision. To take advantage of this feature you need to update the router to the new allow_migrate signature, see the deprecation section for more details.