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

Rastreo (última llamada más reciente) :

File "/app/.heroku/python/lib/python2.7/site-packages/django/core/handlers/base.py", line 115, in get_response response = callback(request, *callback_args, **callback_kwargs)

File "/app/.heroku/python/lib/python2.7/site-packages/newrelic-1.10.0.28/newrelic/api/object_wrapper.py", line 220, in call self._nr_instance, args, kwargs)

File "/app/.heroku/python/lib/python2.7/site-packages/newrelic-1.10.0.28/newrelic/hooks/framework_django.py", line 475, in wrapper return wrapped(*args, **kwargs)

File "/app/.heroku/python/lib/python2.7/site-packages/django/contrib/admin/options.py", line 372, in wrapper return self.admin_site.admin_view(view)(*args, **kwargs)

File "/app/.heroku/python/lib/python2.7/site-packages/django/utils/decorators.py", line 91, in _wrapped_view response = view_func(request, *args, **kwargs)

File "/app/.heroku/python/lib/python2.7/site-packages/django/views/decorators/cache.py", line 89, in _wrapped_view_func response = view_func(request, *args, **kwargs)

File "/app/.heroku/python/lib/python2.7/site-packages/django/contrib/admin/sites.py", line 202, in inner return view(request, *args, **kwargs)

File "/app/.heroku/python/lib/python2.7/site-packages/django/utils/decorators.py", line 25, in _wrapper return bound_func(*args, **kwargs)

File "/app/.heroku/python/lib/python2.7/site-packages/django/utils/decorators.py", line 91, in _wrapped_view response = view_func(request, *args, **kwargs)

File "/app/.heroku/python/lib/python2.7/site-packages/django/utils/decorators.py", line 21, in bound_func return func(self, *args2, **kwargs2)

File "/app/.heroku/python/lib/python2.7/site-packages/django/db/transaction.py", line 223, in inner return func(*args, **kwargs)

File "/app/.heroku/python/lib/python2.7/site-packages/django/db/transaction.py", line 217, in exit self.exiting(exc_value, self.using)

File "/app/.heroku/python/lib/python2.7/site-packages/django/db/transaction.py", line 281, in exiting commit(using=using)

File "/app/.heroku/python/lib/python2.7/site-packages/django/db/transaction.py", line 152, in commit connection.commit()

File "/app/.heroku/python/lib/python2.7/site-packages/django/db/backends/init.py", line 241, in commit self._commit()

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

File "/app/.heroku/python/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py", line 240, in _commit return self.connection.commit()

File "/app/.heroku/python/lib/python2.7/site-packages/newrelic-1.10.0.28/newrelic/hooks/database_dbapi2.py", line 68, in commit return self._nr_connection.commit()

IntegrityError: insert or update on table "django_admin_log" violates foreign key constraint "django_admin_log_user_id_fkey" DETAIL: Key (user_id)=(2) is not present in table "auth_user".

respuesta

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

./manage.py dbshell

DROP TABLE django_admin_log;

y luego:

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

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

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

./manage.py dbshell

Y luego describiendo la django_admin_logtabla:

\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

¿Dónde my_custom_auth_modelestá el nombre de la tabla donde vive su modelo de autenticación personalizado y user_id_refs_id_c0d12874es el nombre de la restricción, que debe copiar para más adelante?

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

./manage makemigrations --empty my_custom_auth_model

Cambié el 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_c0d12874con cualquier nombre de restricción que haya copiado anteriormente. Como puede ver, las dos operaciones y sus reversos 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 django_admin_logtabla ahora debería poder usarse nuevamente, y cualquier cosa que el administrador escriba en ella funcionará en lugar de fallar con un archivo IntegrityError.

Eso porque la django_admin_logtabla todavía contiene una relación de clave externa con la auth_usertabla anterior.

Debe soltar esto y volver a crear 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 :)

EDITED with @dustinfarris Django 1.7+ answer precision

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

python manage.py createsuperuser    
python manage.py migrate

Parece que puede haber habido una mala transacción en algún momento cuando ejecutó esto, podría intentar restablecer completamente su base de datos con:

heroku pg:reset

O podría intentar ingresar psql en la base de datos y examinar/corregir los datos que están creando el problema (que es probable que intente insertar el mismo usuario dos veces):

heroku pg:psql

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 probar.

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