Django talk: Re: Migration auth.0011_update_proxy_permissions from Django 2.2 fails to apply

Sunday, April 7, 2019

Re: Migration auth.0011_update_proxy_permissions from Django 2.2 fails to apply

Hi Julien,

We faced a similar issue, thought it's probably a bug in Django but realised that our unique setup of multiple databases is the reason we are facing this issue unlike many others (except you ofcourse)

It turned out that this data integrity issue will pop up if you run this migration file more than once.

So the thing to keep in mind is that a datamigration files (0011_update_proxy_permissions is a datamigration file) isn't associated with any django model, so a faulty router might make it run on all databases.

We hadn't thought of this scenario in our custom django router either.

Once we fixed our django router to run only on our target database in case of a migration file, this problem was resolved.

For now, forward migrations in auth app are working fine. Reverse migrations are still broken though (something to do with apps.get_models() returning inconsistent results, but that's a problem for another day)

P.S: It would have helped if Django had provided routers with proper hints though. (https://docs.djangoproject.com/en/2.2/howto/writing-migrations/#data-migrations-and-multiple-databases)

On Thursday, April 4, 2019 at 4:38:04 PM UTC+5:30, Julien Enselme wrote:

Hi,

I am trying to update my project to Django 2.2 (we are currently on 2.0.13). When I launch `python manage.py migrate`, I get this error message when migration auth.0011_update_proxy_permissions is applying (full stacktrace is available here):
django.db.utils.IntegrityError: duplicate key value violates unique constraint "idx_18141_auth_permission_content_type_id_01ab375a_uniq"
DETAIL: Key (content_type_id, codename)=(12, add_agency) already exists.

It looks like the migration is trying to re-create already existing entries in the auth_permission table. At first I though it cloud because we recently renamed a model. But after digging and deleting the entries associated with the renamed model from our database in the auth_permission table, the problem still occurs with other proxy models.

I search for a ticket about this on the bug tracker but found nothing.

Can someone help me on this? I guess I can keep deleting problematic entries from our database one by one but it will take a long time and it doesn't look right.

Regards,
Julien Enselme