Opened 6 years ago

Last modified 6 weeks ago

#10827 new Bug

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

Reported by: seanl Owned by: nobody
Component: contrib.auth Version: master
Severity: Normal Keywords:
Cc: jodym@…, chris+django@…, rjalves@…, jorgecarleitao, julenx@…, jarus 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 seanl 6 years ago.
contenttype_error_on_TransactionTestCase.tar.bz2 (3.5 KB) - added by rjalves 3 years ago.
Test Django project - created with Django 1.4.5

Download all attachments as: .zip

Change History (23)

comment:1 Changed 6 years ago by seanl

  • Has patch set
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 6 years ago by Alex

  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 6 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 5 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 5 years ago by SmileyChris

  • Severity set to Normal
  • Type set to Bug

comment:6 Changed 4 years ago by julien

  • Needs tests set

comment:7 Changed 4 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 3 years ago by jodym@…

  • Cc jodym@… added

comment:9 Changed 3 years ago by anonymous

A workaround based on comment 7 is available here:

comment:10 Changed 3 years ago by gcc

+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 3 years ago by gcc

  • Cc chris+django@… added

Changed 3 years ago by rjalves

Test Django project - created with Django 1.4.5

comment:12 Changed 3 years ago by rjalves

  • 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 3 years ago by rjalves (previous) (diff)

comment:13 Changed 3 years ago by rjalves

Another duplicate: #6259

comment:14 Changed 2 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 22 months ago by jorgecarleitao

  • Cc jorgecarleitao added

comment:16 Changed 20 months ago by julen

  • Cc julenx@… added

comment:17 Changed 13 months ago by jarus

  • Cc jarus added

comment:18 Changed 7 weeks ago by guettli

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 7 weeks ago by guettli

The six years old patch solved the issue for me:


comment:20 Changed 7 weeks ago by guettli

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 6 weeks ago by guettli

I created a pull request:

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

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