Problemas con los tipos de contenido al cargar un dispositivo en Django

Tengo problemas para cargar los accesorios de Django en mi base de datos MySQL debido a conflictos de tipos de contenido. Primero intenté descargar los datos solo de mi aplicación de esta manera:

./manage.py dumpdata escola > fixture.json

pero seguía teniendo problemas de claves foráneas faltantes, porque mi aplicación "escola" usa tablas de otras aplicaciones. Seguí agregando aplicaciones adicionales hasta que llegué a esto:

./manage.py dumpdata contenttypes auth escola > fixture.json

Ahora el problema es la siguiente violación de la restricción cuando trato de cargar los datos como un dispositivo de prueba:

IntegrityError: (1062, "Duplicate entry 'escola-t23aluno' for key 2")

Parece que el problema es que Django está intentando recrear dinámicamente tipos de contenido con diferentes valores de clave primaria que entran en conflicto con los valores de clave primaria del dispositivo. Esto parece ser el mismo que el error documentado aquí: http://code.djangoproject.com/ticket/7052

El problema es que la solución alternativa recomendada es volcar la aplicación contenttypes que ya estoy haciendo. ¿Lo que da? Si hace alguna diferencia, tengo algunos permisos de modelo personalizados como se documenta aquí: http://docs.djangoproject.com/en/dev/ref/models/options/#permissions

manage.py dumpdata --naturalutilizará una representación más duradera de claves externas. En django se les llama "claves naturales". Por ejemplo:

• Permission.codename se usa a favor de Permission.id
• User.username se usa a favor de User.id

Leer más: sección de claves naturales en "serialización de objetos django"

Algunos otros argumentos útiles para dumpdata:

• --indent=4 hágalo legible por humanos.
• -e sessions excluir datos de sesión
• -e admin excluir el historial de acciones de administración en el sitio de administración
• -e contenttypes -e auth.Permissionexcluir objetos que se recrean automáticamente del esquema cada vez durante syncdb. Úselo solo junto con --naturalo de lo contrario podría terminar con números de identificación mal alineados.

Sí, esto es realmente irritante. Durante un tiempo lo solucioné haciendo un "restablecimiento de manage.py" en la aplicación contenttypes antes de cargar el dispositivo (para deshacerme de los datos de contenttypes generados automáticamente que diferían de la versión descargada). Eso funcionó, pero finalmente me cansé de las molestias y de los accesorios abandonados por completo a favor de los volcados SQL directos (por supuesto, luego pierdes la portabilidad de la base de datos).

actualizar : la mejor respuesta es usar la --naturalbandera para dumpdata, como se indica en una respuesta a continuación. Esa bandera aún no existía cuando escribí esta respuesta.

Intente omitir los tipos de contenido al crear el accesorio:

./manage.py dumpdata --exclude contenttypes > fixture.json

Me funcionó en una situación similar para las pruebas unitarias, ¡su conocimiento sobre los tipos de contenido realmente ayudó!

Las respuestas aquí son todas viejas ... A partir de 2017, la mejor respuesta es:

manage.py dumpdata --natural-foreign --natural-primary -e contenttypes -e auth.Permission --indent 4

No estaba usando MySQL, sino que estaba importando algunos datos de un servidor en vivo a sqlite. Borrar los contenttypesdatos de la aplicación antes de realizar el proceso loaddatafuncionó:

from django.contrib.contenttypes.models import ContentType
ContentType.objects.all().delete()
quit()

Y entonces

python manage.py loaddata data.json

Resolví este problema en mis casos de prueba restableciendo la aplicación contenttypes de la prueba unitaria antes de cargar mi archivo de volcado. Carl sugirió esto ya usando el manage.pycomando y yo hago lo mismo solo usando el call_commandmétodo:

>>> from django.core import management
>>> management.call_command("flush", verbosity=0, interactive=False)
>>> management.call_command("reset", "contenttypes", verbosity=0, interactive=False)
>>> management.call_command("loaddata", "full_test_data.json", verbosity=0)

Mi full_test_data.jsondispositivo contiene el volcado de la aplicación contenttypes que corresponde al resto de los datos de prueba. Al restablecer la aplicación antes de cargarla, evita la clave duplicada IntegrityError.

python manage.py dumpdata --natural-primary --exclude=contenttypes --exclude=auth.Permission --exclude=admin.logentry --exclude=sessions.session --indent 4 > initial_data.json

Esto funciona para mi. Aquí estoy excluyendo todo lo que burbujea en los modelos reales.

• Si ve cualquier otro modelo que no sean los modelos que creó, puede excluirlos de forma segura. Un inconveniente de este enfoque es que pierde tanto los datos de registro como los de autenticación.

Debe utilizar claves naturales para representar cualquier clave externa y relaciones de varios a varios. Además, podría ser una buena idea excluir la sessiontabla en la sessionsaplicación y la logentrytabla en la adminaplicación.

Django 1.7+

python manage.py dumpdata --natural-foreign --exclude contenttypes --exclude auth.permission --exclude admin.logentry --exclude sessions.session --indent 4 > fixture.json

Django <1.7

python manage.py dumpdata --natural --exclude contenttypes --exclude auth.permission --exclude admin.logentry --exclude sessions.session --indent 4 > fixture.json

Según la documentación de Django , --naturalse ha desaprobado en la versión 1.7, por lo que la opción --natural-foreigndebería usarse en su lugar.

También puede omitir la clave principal en los datos serializados de este objeto, ya que se puede calcular durante la deserialización pasando la --natural-primarymarca.

python manage.py dumpdata --natural-foreign --natural-primary --exclude contenttypes --exclude auth.permission --exclude admin.logentry --exclude sessions.session --indent 4 > fixture.json

./manage.py dumpdata app.Model --natural-foreign

cambiará

  "content_type": 123

a

  "content_type": [
    "app_label",
    "model"
  ],

Y el accesorio funciona por TestCaseahora

Django 2.2.5

python manage.py dumpdata --exclude=contenttypes > datadump.json

Me ayudó

Voy a dar otra posible respuesta que acabo de descubrir. Quizás ayude al OP, quizás ayude a alguien más.

Tengo una tabla de relaciones de muchos a muchos. Tiene una clave primaria y las dos claves foráneas para las otras tablas. Descubrí que si tengo una entrada en el dispositivo cuyas dos claves externas son iguales a otra entrada que ya está en la tabla con un pk diferente , fallará. Las tablas de relaciones M2M tienen un "conjunto único" para las dos claves externas.

Entonces, si se trata de una relación M2M que se está rompiendo, mire las claves externas que está agregando, mire su base de datos para ver si ese par de FK ya figura en una PK diferente.

Es muy, muy molesto ... Esto me muerde cada vez.

Traté de volcar datos con --exclude contenttypes y --natural, siempre tengo problemas ...

Lo que funciona mejor para mí es simplemente hacer un truncate table django_content_type;después de syncdb y LUEGO cargar los datos.

Por supuesto, para la carga automática initial_data.json, estás en caída libre.

A veces me había encontrado con un error similar. Resultó que estaba intentando cargar los dispositivos antes de crear las tablas necesarias. Así que lo hice:

$ python manage.py makemigrations
$ python manage.py migrate
$ python manage.py loaddata fixtures/initial_data.json

Y funcionó como un encanto

En mi caso, había descargado los datos de auth( ./manage.py dumpddata auth > fixtures/auth.json) para usar el dispositivo con fines de prueba.

El desarrollo continuó y eliminé la mayoría de los modelos que había definido models.pyy fue entonces cuando comencé a ver este molesto problema.

Mi solución fue volver a regenerar el accesorio auth.json. Este había eliminado muchas entradas auth.permissionrelacionadas con los modelos antiguos que tenía.

Probé todos los métodos de arriba, nada funcionó para mí. Tengo que excluir el modelo de autenticación completo y funciona bien.

python manage.py dumpdata --natural-primary --exclude=contenttypes --exclude=auth --exclude=admin.logentry --exclude=sessions.session --indent 4 > live.json