Problèmes avec contenttypes lors du chargement d'un appareil de Django

Question

J'ai un problème de chargement de Django luminaires dans ma base de données MySQL à cause de contenttypes conflits. J'ai d'abord essayé le dumping des données provenant uniquement de mon application comme ceci:

./manage.py dumpdata escola > fixture.json

mais j'ai continué à obtenir de clé étrangère manquante de problèmes, parce que mon application "escola" utilise des tables à partir d'autres applications. J'ai continué à ajouter des applications supplémentaires, jusqu'à ce que je suis arrivé à ceci:

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

Maintenant, le problème est le suivant violation de contrainte lorsque j'essaie de charger les données d'une installation de test:

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

Il semble que le problème est que Django est d'essayer de recréer dynamiquement contenttypes avec différentes valeurs de clé primaire qui sont en conflit avec les valeurs de clé primaire de l'appareil. Cela semble être le même bogue comme indiqué ici: http://code.djangoproject.com/ticket/7052

Le problème est que la solution recommandée est de jeter les contenttypes app qui je suis déjà en train de faire!? Ce qui donne? Si cela fait une différence j'ai quelques modèles personnalisés autorisations, comme indiqué ici: http://docs.djangoproject.com/en/dev/ref/models/options/#permissions

Answer 1

manage.py dumpdata --natural va utiliser une approche plus durable de la représentation de clés étrangères. Ils sont appelés "les clefs naturelles". Par exemple:

• Permission.codename est utilisé en faveur de l' Permission.id
• User.username est utilisé en faveur de l' User.id

Lire la suite: des clés naturelles dans la section "sérialisation d'objets django"

Certains autres arguments utiles pour dumpdata:

• --indent=4 le rendre lisible par l'homme.
• -e sessions d'exclure les données de session
• -e admin d'exclure de l'histoire de l'admin actions sur le site d'administration
• -e contenttypes -e auth.Permission exclure des objets qui sont recréés automatiquement à partir du schéma à chaque fois lors d' syncdb. Seulement l'utiliser avec d' --natural sinon vous risquez de vous retrouver avec mal alignées les numéros d'identification.

Answer 2

Oui, c'est vraiment irritant. Pour un moment, j'ai travaillé autour d'elle en faisant un "manage.py reset" sur le contenttypes application avant le chargement de l'appareil (pour se débarrasser de l'générés automatiquement contenttypes de données différente de la version sous-évaluées). Qui a travaillé, mais finalement je suis tombé malade de les tracas et abandonné luminaires entièrement en faveur de la droite dumps SQL (bien sûr, vous perdez la DB de la portabilité).

mise à jour - la meilleure réponse est d'utiliser l' --natural le drapeau en dumpdata, comme indiqué dans la réponse ci-dessous. Le drapeau n'existait pas encore quand j'ai écrit cette réponse.

Answer 3

Essayez de sauter contenttypes lors de la création de luminaire:

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

Il a travaillé pour moi dans une situation similaire pour les tests unitaires, votre point de vue concernant la contenttypes vraiment aidé!

Answer 4

J'ai résolu ce problème dans mon cas de test par la réinitialisation de la contenttypes application à partir de l'unité de test avant le chargement de mon fichier de vidage. Charles a proposé ce déjà à l'aide de l' manage.py commande et je fais la même chose en utilisant uniquement l' call_command méthode:

>>> 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)

Mon full_test_data.json - support contient le contenttypes application de vidage qui correspond le reste des données de test. Par la réinitialisation de l'application avant le chargement, il empêche le double de la clé IntegrityError.

Answer 5

Je vais donner une autre réponse possible que je viens de comprendre. Peut-être que ça va aider l'OP, peut-être que ça va aider quelqu'un d'autre.

J'ai un plusieurs-à-plusieurs table de relation. Il possède une clé primaire et les deux clés étrangères pour les autres tables. J'ai trouvé que si j'ai une entrée dans l'appareil, dont les deux clés étrangères sont les mêmes que pour une autre entrée déjà dans la table avec un différent pk, ce sera un échec. M2M relation des tables ont une "unique ensemble pour" les deux clés étrangères.

Alors, si c'est un M2M relation qui est en train de rompre, regardez les clés étrangères, c'est l'ajout d', examinez votre base de données pour voir si cette paire de clefs étrangères sont déjà répertoriés sous un autre PK.