Error de integridad en django_admin_log después de actualizar el sitio existente al nuevo modelo de usuario de Django 1.5

django-1.5

Question

Aparentemente, después de agregar mi nueva tabla de usuarios al sitio, django_admin_log todavía tiene una tabla de FK a auth_user. ¿Alguna forma de abordar esto? No vi este problema en la puesta en escena o localmente, así que algo extraño debe haber ocurrido.

Traceback (última llamada más reciente) :

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/core/handlers/base.py", línea 115, en get_response response = callback (solicitud, * callback_args, ** callback_kwargs)

Archivo "/app/.heroku/python/lib/python2.7/site-packages/newrelic-1.10.0.28/newrelic/api/object_wrapper.py", línea 220, en la llamada self._nr_instance, args, kwargs)

Archivo "/app/.heroku/python/lib/python2.7/site-packages/newrelic-1.10.0.28/newrelic/hooks/framework_django.py", línea 475, envuelta en el envoltorio (* args, ** kwargs)

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/contrib/admin/options.py", línea 372, en el envoltorio, devuelva self.admin_site.admin_view (ver) (* args, * * kwargs)

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/utils/decorators.py", línea 91, en _wrapped_view response = view_func (solicitud, * args, ** kwargs)

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/views/decorators/cache.py", línea 89, en _wrapped_view_func response = view_func (request, * args, ** kwargs)

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/contrib/admin/sites.py", línea 202, en vista de retorno interno (solicitud, * args, ** kwargs)

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/utils/decorators.py", línea 25, en _wrapper return bound_func (* args, ** kwargs)

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/utils/decorators.py", línea 91, en _wrapped_view response = view_func (solicitud, * args, ** kwargs)

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/utils/decorators.py", línea 21, en bound_func return func (self, * args2, ** kwargs2)

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/db/transaction.py", línea 223, en la función de retorno interno (* args, ** kwargs)

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/db/transaction.py", línea 217, en exit self.exiting (exc_value, self.using)

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/db/transaction.py", línea 281, al salir de commit (utilizando = using)

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/db/transaction.py", línea 152, en commit connection.commit ()

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/db/backends/ init .py", línea 241, en commit self._commit ()

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py", línea 242, en _commit six.reraise (utils.IntegrityError, utils.IntegrityError ( * tuple (e.args)), sys.exc_info () [2])

Archivo "/app/.heroku/python/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py", línea 240, en _commit return self.connection.commit ()

Archivo "/app/.heroku/python/lib/python2.7/site-packages/newrelic-1.10.0.28/newrelic/hooks/database_dbapi2.py", línea 68, en confirmación de devolución self._nr_connection.commit ()

IntegrityError: insertar o actualizar en la tabla "django_admin_log" viola la restricción de clave foránea "django_admin_log_user_id_fkey" DETALLE: La clave (user_id) = (2) no está presente en la tabla "auth_user".

Answer 1

Creo que la aplicación de administración solo instala la tabla django_admin_log.

python manage.py sqlclear admin

BEGIN;
DROP TABLE "django_admin_log";

COMMIT;

Así que también puedes intentarlo.

python manage.py sqlclear admin | python manage.py dbshell
python manage.py syncdb

Answer 2

Elimine la base de datos y cree un superusuario, finalmente ejecute migrate :

python manage.py createsuperuser    
python manage.py migrate

Answer 3

Parece que puede haber habido una transacción incorrecta como un momento en el que ejecutó esto, podría intentar restablecer completamente su base de datos con:

heroku pg:reset

O puede intentar hacer psql en la base de datos y examinar / corregir los datos que crean el problema (que es probable que intente insertar el mismo usuario dos veces):

heroku pg:psql

Answer 4

Si está en Django 1.7 o posterior, agregar una migración adecuada para modificar la tabla django_admin_log es una opción mucho mejor en mi opinión. De esa manera, puede mantener cualquier entrada de registro existente, que en realidad puede ser algo para lo que tenga uso. Hacer tal alteración requiere que el campo de identificación sea el mismo, por ejemplo, tenga el mismo nombre, etc.

Primero tendrá que averiguar el nombre de la restricción, que se puede hacer ingresando al shell de la base de datos:

./manage.py dbshell

Y luego describiendo la tabla django_admin_log :

/d+ django_admin_log;

Esto tendrá la restricción en la salida, algo así como:

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

Donde my_custom_auth_model es el nombre de la tabla donde vive su modelo de autenticación personalizado, y user_id_refs_id_c0d12874 es el nombre de la restricción, que debe copiar para más adelante.

A continuación, crea una nueva migración:

./manage makemigrations --empty my_custom_auth_model

0000_alter_admin_log_constraint.py nombre de mi nueva migración (es decir, 0000_alter_admin_log_constraint.py ) para tener algo útil en lugar de una marca de fecha en el nombre del archivo. Sin embargo, no use cuatro ceros, use lo que se asignó al crear la migración :)

En la nueva migración, esto es lo que usé para las operaciones:

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''''''),
]

Sustituya user_id_refs_id_c0d12874 con el nombre de restricción que haya copiado anteriormente. Como puede ver, las dos operaciones y sus reveses son inversos entre sí, lo que significa que también puede mover estas migraciones hacia atrás.

Ahora, todo lo que tienes que hacer es aplicar la nueva migración:

./manage.py migrate

La tabla django_admin_log ahora debería poder usarse nuevamente, y cualquier cosa que escriba el administrador en ella funcionará en lugar de fallar con un IntegrityError .

Answer 5

Si te encuentras con esto y estás usando> = 1.7:

./manage.py dbshell

DROP TABLE django_admin_log;

y entonces:

./manage.py sqlmigrate admin 0001 | ./manage.py dbshell

Answer 6

Esto se debe a que la tabla django_admin_log aún contiene una relación de clave externa a la antigua tabla auth_user .

Necesitas soltar esto y recrear la tabla.

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

Para Django <1.7

$ heroku run python manage.py syncdb

Y para Django> = 1.7

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

Y eso es :)

EDITADO con @dustinfarris Django 1.7+ precisión de respuesta