* 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.
On Wednesday, October 28, 2015 at 12:51:44 PM UTC-4, Gergely Polonkai wrote:
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
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6e15d12c-f8ce-4daa-a795-69c169db43ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment