Opened 8 years ago

Last modified 12 months ago

#10827 new Bug

django.auth create_permissions must clear the content type cache before creating permissions

Reported by: Sean Legassick Owned by:
Component: contrib.auth Version: master
Severity: Normal Keywords:
Cc: jodym@…, chris+django@…, rjalves@…, jorgecarleitao, julenx@…, Christoph Heer, Jonas Trappenberg Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no


I hit a problem which took some time to track down, where at the DB flush stage in a sequence of tests (using TransactionTestCase) the recreation of permissions was failing with a FK constraint error.

This was caused by inserting a permission referring to a content type that didn't exist in the DB.

This happened because the content type was still in the cache, even thought the django_content_type table had been truncated.

The cache hadn't been cleared because post_syncdb signal dispatch had called create_permissions before calling update_contenttypes (which does clear the cache and recreate the content types correctly).

The real problem here is that create_permissions and update_contenttypes are both connected to the post_syncdb signal, with the former depending on the latter having been run first, but the dispatcher doesn't guarantee order of dispatch (or rather it dispatches in the order the signal handlers are connected, but that order depends on the order in which modules are loading which is not well-defined). Unfortunately that's a hard problem to solve, and I don't have any ideas about that short of substantive changes to the signal dispatcher.

An easier solution to this particular problem is for create_permissions to clear the content types cache before it recreates permissions, that way the necesarry content types will be created as needed (see attached patch).

Attachments (2)

10827-create-permissions-must-clear-content-type-cache.diff (561 bytes) - added by Sean Legassick 8 years ago.
contenttype_error_on_TransactionTestCase.tar.bz2 (3.5 KB) - added by Renato Alves 4 years ago.
Test Django project - created with Django 1.4.5

Download all attachments as: .zip

Change History (28)

comment:1 Changed 8 years ago by Sean Legassick

Has patch: set

comment:2 Changed 7 years ago by Alex Gaynor

Triage Stage: UnreviewedAccepted

comment:3 Changed 7 years ago by Jason Yan <tailofthesun@…>

I just got hit by this same issue and worked around it in a similar manner. I instead removed the signal that was connected to update_contenttypes and moved the update_contenttypes call to

For anyone that might be possibly searching for this, here's the exception from the tests without the fix:

IntegrityError: insert or update on table "auth_permission" violates foreign key constraint "content_type_id_refs_id_728de91f"
DETAIL:  Key (content_type_id)=(2) is not present in table "django_content_type".

comment:4 Changed 6 years ago by PeterRussell

It seems that the reason that this happens is that the syncdb command is firing the post_syncdb signal for each application, as returned from get_apps() [source:/django/trunk/django/core/management/ here]. Get_apps appears to return apps in app-name order (see [source:/django/trunk/django/db/models/ here]), and auth comes before contenttypes asciibetically. It seems the right solution is probably to have a separate post_contenttypes_refreshed signal, and have create_permissions listen for that. It would also be great if updating permissions could fire its own signal, so you can update groups etc based on that. (We've been having a somewhat similar issue).

comment:5 Changed 6 years ago by Chris Beaven

Severity: Normal
Type: Bug

comment:6 Changed 6 years ago by Julien Phalip

Needs tests: set

comment:7 Changed 5 years ago by orb@…

Easy pickings: unset
UI/UX: unset

I'm having this problem too. We worked around it by extending TransactionTestCase so that _pre_setup() invokes ContentType.objects.clear_cache(). I'd really love to see a solution to this.

comment:8 Changed 5 years ago by jodym@…

Cc: jodym@… added

comment:9 Changed 5 years ago by anonymous

A workaround based on comment 7 is available here:

comment:10 Changed 5 years ago by Chris Wilson

+1. This just bit us as well.

I think if flush is going to invalidate caches (which it appears to do), then it should be sending a signal that allows holders of caches to respond appropriately. So something like this in

for app in set(all_models):
    models.signals.post_flush.send(sender=app, app=app,
        created_models=created_models, verbosity=verbosity,
        interactive=interactive, db=db)
emit_post_sync_signal(set(all_models), verbosity, interactive, db)

Assuming a new signal flush which ContentTypeManager listens for, and then flushes its cache.

comment:11 Changed 5 years ago by Chris Wilson

Cc: chris+django@… added

Changed 4 years ago by Renato Alves

Test Django project - created with Django 1.4.5

comment:12 Changed 4 years ago by Renato Alves

Cc: rjalves@… added

The attached file is a fresh django project created with Django 1.4.5 which reproduces the mentioned error.
NOTE: This error is not reproducible with the sqlite backend (MySQL was not tested but was reported to fail with InnoDB in other tickets #9207).

Ticket #9207 is closed as fixed but due to lack of reproducibility. From the error it looks like a duplicate of the current.
The workaround described on comment 3 from #9207 also solves the problem (putting contrib.contenttypes before contrib.auth in INSTALLED_APPS).

PS: I don't know if there's any reason why INSTALLED_APPS has the current order but having invert the order could workaround this problem.

Last edited 4 years ago by Renato Alves (previous) (diff)

comment:13 Changed 4 years ago by Renato Alves

Another duplicate: #6259

comment:14 Changed 3 years ago by anonymous

I think I have run into the same problem while trying to use Selenium to test Django admin capabilities. When I try to update a user's permissions, I get the FK error. You can see [my code and issue on SO]( So I think this is still a present bug in Django 1.5.1 / MySQL.

comment:15 Changed 3 years ago by jorgecarleitao

Cc: jorgecarleitao added

comment:16 Changed 3 years ago by julen

Cc: julenx@… added

comment:17 Changed 2 years ago by Christoph Heer

Cc: Christoph Heer added

comment:18 Changed 17 months ago by Thomas Güttler

I think this bug is still alive in Django1.7.

I get this traceback:

File ".../django/core/management/", line 385, in execute_from_command_line
File ".../django/core/management/", line 377, in execute
File ".../django/core/management/", line 288, in run_from_argv
  self.execute(*args, **options.__dict__)
File ".../django/core/management/", line 338, in execute
  output = self.handle(*args, **options)
File ".../django/core/management/commands/", line 165, in handle
  emit_post_migrate_signal(created_models, self.verbosity, self.interactive, connection.alias)
File ".../django/core/management/", line 268, in emit_post_migrate_signal
File ".../django/dispatch/", line 198, in send
  response = receiver(signal=self, sender=sender, **named)
File ".../django/contrib/auth/management/", line 117, in create_permissions
File ".../django/db/models/", line 410, in bulk_create
  self._batched_insert(objs_without_pk, fields, batch_size)
File ".../django/db/", line 339, in __exit__
File ".../django/db/backends/", line 176, in commit
File ".../django/db/backends/", line 145, in _commit
  return self.connection.commit()
File ".../django/db/", line 94, in __exit__
  six.reraise(dj_exc_type, dj_exc_value, traceback)
File ".../django/db/backends/", line 145, in _commit
  return self.connection.commit()

django.db.utils.IntegrityError: insert or update on table "auth_permission" violates foreign key constraint "auth_content_type_id_508cf46651277a81_fk_django_content_type_id"
 DETAIL:  Key (content_type_id)=(1) is not present in table "django_content_type".


comment:19 Changed 17 months ago by Thomas Güttler

The six years old patch solved the issue for me:


comment:20 Changed 17 months ago by Thomas Güttler

A work around is this line in your migration:

from django.contrib.contenttypes.models import ContentType

class Migration(migrations.Migration):
    operations = [
        migrations.RunPython(lambda apps, schema_editor: ContentType.objects.clear_cache()),

comment:21 Changed 17 months ago by Thomas Güttler

I created a pull request:

It includes a test. Thanks to Tim Graham for the support.

comment:22 Changed 15 months ago by Peter Bengtsson

I can confirm that this is still a bug in Django 1.7.
I can't speak of the PR because I haven't studied it but making sure the order of the INSTALLED_APPS is right, as per did solve it for me.

comment:23 Changed 15 months ago by Koen Vossen

Owner: changed from nobody to Koen Vossen
Status: newassigned

comment:24 Changed 15 months ago by Koen Vossen

Owner: Koen Vossen deleted
Status: assignednew

Don't forget to use a database that checks foreign key constraints instead of the testrunner's default sqlite when trying to reproduce this bug.

Last edited 15 months ago by Koen Vossen (previous) (diff)

comment:25 Changed 14 months ago by Jonas Trappenberg

Cc: Jonas Trappenberg added

comment:26 Changed 12 months ago by Sven R. Kunze

@guettli @timgraham

It just works. Nice. Thanks for that suggestion.

Note: See TracTickets for help on using tickets.
Back to Top