[Django]-Integrity error on django_admin_log after updating existing site to new Django 1.5 user model

20πŸ‘

βœ…

That because the django_admin_log table still contains a foreign key relation to the old auth_user table.

You need to drop this and recreate the table.

$ heroku pg:psql
psql => drop table django_admin_log;

For Django < 1.7

$ heroku run python manage.py syncdb

And for Django >= 1.7

$ ./manage.py sqlmigrate admin 0001 | heroku pg:psql

And that’s it πŸ™‚

EDITED with @dustinfarris Django 1.7+ answer precision

πŸ‘€dulaccc

37πŸ‘

If you run into this and you’re using >=1.7:

./manage.py dbshell

DROP TABLE django_admin_log;

and then:

./manage.py sqlmigrate admin 0001 | ./manage.py dbshell
πŸ‘€dustinfarris

8πŸ‘

If you are on Django 1.7 or later, adding a proper migration for altering the django_admin_log table is a much better option in my opinion. That way you can keep any existing log entries, which may actually be something you have use for. Doing such an alter requires that the id field is the same, e.g. has the same name etc.

First you will have to find out the name of the constraint, which can be done by going into the database shell:

./manage.py dbshell

And then describing the django_admin_log table:

\d+ django_admin_log;

This will have the constraint in the output, something like:

"user_id_refs_id_c0d12874" FOREIGN KEY (user_id) REFERENCES my_custom_auth_model(id) DEFERRABLE INITIALLY DEFERRED

Where my_custom_auth_model is the name of the table where your custom auth model lives, and user_id_refs_id_c0d12874 is the name of the constraint, which you should copy for later.

Next, create a new migration:

./manage makemigrations --empty my_custom_auth_model

I renamed my new migration (i.e. 0000_alter_admin_log_constraint.py) to have something useful instead of a datestamp in the filename. Don’t use four zeros though, use whatever was assigned when creating the migration πŸ™‚

In the new migration, this is what I used for operations:

operations = [
    migrations.RunSQL(
        '''ALTER TABLE django_admin_log DROP CONSTRAINT user_id_refs_id_c0d12874''',
        reverse_sql='''ALTER TABLE django_admin_log ADD CONSTRAINT user_id_refs_id_c0d12874
            FOREIGN KEY (user_id) REFERENCES auth_user(id) DEFERRABLE INITIALLY DEFERRED'''),
    migrations.RunSQL(
        '''ALTER TABLE django_admin_log ADD CONSTRAINT user_id_refs_id_c0d12874
            FOREIGN KEY (user_id) REFERENCES my_custom_auth_model(id) DEFERRABLE INITIALLY DEFERRED''',
        reverse_sql='''ALTER TABLE django_admin_log DROP CONSTRAINT user_id_refs_id_c0d12874'''),
]

Substitute user_id_refs_id_c0d12874 with whatever constraint name you copied previously. As you can see, the two operations and their reverses are inverses of each other, meaning you can move this migrations backwards as well.

Now, all you have to do is to apply the new migration:

./manage.py migrate

The django_admin_log table should now be usable again, and anything in admin writing to it will work instead of failing with an IntegrityError.

0πŸ‘

It appears as though there may have been a bad transaction as some point when you ran this, you could try fully resetting your db with:

heroku pg:reset

Or you could attempt to psql into the database and examine/correct the data thats creating the issue (which is likely that its trying to insert the same user twice):

heroku pg:psql

0πŸ‘

I think that admin app only installs django_admin_log table.

python manage.py sqlclear admin

BEGIN;
DROP TABLE "django_admin_log";

COMMIT;

So you can also try.

python manage.py sqlclear admin | python manage.py dbshell
python manage.py syncdb
πŸ‘€Arthur Alvim

-1πŸ‘

Delete the database and create a superuser, finally run migrate:

python manage.py createsuperuser    
python manage.py migrate
πŸ‘€Weipeng Liu

Leave a comment