Russell,
Thank you for posting this great answer on why this error may be occurring.
I was getting this error, and for the live of me (1-2 days), couldn't
figure out the issue. Thank you!!
On Wednesday, April 2, 2014 at 2:23:48 PM UTC-7, Russell Keith-Magee wrote:
>
>
> On Wed, Apr 2, 2014 at 1:23 PM, Greg Taylor <snaggl...@gmail.com
> <javascript:>> wrote:
>
>> I've got a project running Django 1.4, Postgres 3, Python 2.7. Our tests
>> get about halfway through, then we get a sudden flood of errors showing
>> that the django_content_type table may be empty:
>>
>>
>> ......................................................EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
>>
>> Once the errors stop, they continue to the end of the test run. Here's
>> the traceback for all of the errors:
>>
>> Traceback (most recent call last):
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/test/testcases.py",
>>
>> line 502, in __call__
>>
>> self._pre_setup()
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/test/testcases.py",
>>
>> line 463, in _pre_setup
>>
>> self._fixture_setup()
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/test/testcases.py",
>>
>> line 475, in _fixture_setup
>>
>> call_command('flush', verbosity=0, interactive=False, database=db)
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/core/management/__init__.py",
>>
>> line 150, in call_command
>>
>> return klass.execute(*args, **defaults)
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/raven/contrib/django/management/__init__.py",
>>
>> line 37, in new_execute
>>
>> return original_func(self, *args, **kwargs)
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/core/management/base.py",
>>
>> line 232, in execute
>>
>> output = self.handle(*args, **options)
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/core/management/base.py",
>>
>> line 371, in handle
>>
>> return self.handle_noargs(**options)
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/core/management/commands/flush.py",
>>
>> line 77, in handle_noargs
>>
>> emit_post_sync_signal(set(all_models), verbosity, interactive, db)
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/core/management/sql.py",
>>
>> line 189, in emit_post_sync_signal
>>
>> interactive=interactive, db=db)
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py",
>>
>> line 172, in send
>>
>> response = receiver(signal=self, sender=sender, **named)
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py",
>>
>> line 54, in create_permissions
>>
>> auth_app.Permission.objects.bulk_create(objs)
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/db/models/manager.py",
>>
>> line 140, in bulk_create
>>
>> return self.get_query_set().bulk_create(*args, **kwargs)
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/db/models/query.py",
>>
>> line 421, in bulk_create
>>
>> transaction.commit(using=self.db)
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/db/transaction.py",
>>
>> line 153, in commit
>>
>> connection.commit()
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/db/backends/__init__.py",
>>
>> line 234, in commit
>>
>> self._commit()
>>
>> File
>> "/home/cbweb/.virtualenvs/coursebook/local/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py",
>>
>> line 235, in _commit
>>
>> return self.connection.commit()
>>
>> IntegrityError: insert or update on table "auth_permission" violates
>> foreign key constraint "content_type_id_refs_id_728de91f"
>>
>> DETAIL: Key (content_type_id)=(1) is not present in table
>> "django_content_type".
>>
>>
>> This is pretty bizarre, but it's probably something we're doing. Has
>> anyone ran into something like this before? I can't find anywhere that
>> we're deleting content types (which the error seems to suggest is
>> happening).
>>
>
> Hi Greg,
>
> It's not a common error, but I have seen it.
>
> There are two possible causes.
>
> The first is a bad fixture. If your test has a fixture file, and that
> fixture file includes or references a permission by primary key value,
> you'll have problems. This is because content types are programmatically
> allocated at runtime, and the order (and thus the IDs) aren't
> deterministic. If you reference ID X, there's no guarantee that X will
> exist, or that it is the content type you want.
>
> The fix here is to use a natural key to reference content types,
> permissions, and any other dynamically created content. See the following
> link for details.
>
> https://docs.djangoproject.com/en/dev/topics/serialization/#natural-keys
>
> The second possibility is that you've got a corrupted content type cache.
> Django's content type system has an internal cache for performance reasons.
> This is unrelated to memcache or anything like that - it's a simple
> in-process, in-memory cache to avoid repeated lookups for content types.
>
> In most cases, it's completely transparent. You look up a content type for
> your model class, and the content type is stored. The next time you look
> for the same content type, it's only a dictionary lookup, not a database
> hit.
>
> In testing, the same is true - the first hit is expensive, future hits are
> free.
>
> However - during testing - there are certain use cases that can cause
> problems. If your tests are creating new content types (e.g., defining and
> registering a new model), this changes the values in your content type
> table, invalidating your cache. Django doesn't have any builtin capability
> to invalidate the content type cache, and so you end up getting errors
> about invalid constraints, or non existent models, and so on.
>
> The solution - find the test case where you're doing this, and in the
> setUp() and tearDown() methods, invoke ContentType.objects.clear_cache().
> This flushes the contenttype cache, and makes sure that each test runs with
> a clean starting point.
>
> I hope that helps!
>
> Yours,
> Russ Magee %-)
>
>
--
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+unsubscr...@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/b0f95129-818b-4d32-98ab-ff15b6265365%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
