Problemy z typami zawartości podczas ładowania urządzenia w Django

Mam problem z ładowaniem urządzeń Django do mojej bazy danych MySQL z powodu konfliktów contenttypes. Najpierw próbowałem zrzucić dane tylko z mojej aplikacji w następujący sposób:

./manage.py dumpdata escola > fixture.json

ale ciągle pojawiały się problemy z brakującymi kluczami obcymi, ponieważ moja aplikacja „escola” używa tabel z innych aplikacji. Dodawałem kolejne aplikacje, aż doszedłem do tego:

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

Teraz problemem jest następujące naruszenie ograniczenia, gdy próbuję załadować dane jako urządzenie testowe:

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

Wygląda na to, że problem polega na tym, że Django próbuje dynamicznie odtworzyć typy zawartości z różnymi wartościami klucza podstawowego, które kolidują z wartościami klucza podstawowego z urządzenia. Wygląda na to, że jest to to samo, co błąd udokumentowany tutaj: http://code.djangoproject.com/ticket/7052

Problem w tym, że zalecanym obejściem jest zrzucenie aplikacji contenttypes, którą już robię !? Co daje? Jeśli to robi różnicę, mam pewne uprawnienia do modelu niestandardowego, jak udokumentowano tutaj: http://docs.djangoproject.com/en/dev/ref/models/options/#permissions

manage.py dumpdata --naturalużyje bardziej trwałej reprezentacji kluczy obcych. W django nazywane są one „naturalnymi kluczami”. Na przykład:

• Permission.codename jest używany na rzecz Permission.id
• User.username jest używany na rzecz User.id

Czytaj więcej: sekcja kluczy naturalnych w "serializowaniu obiektów django"

Kilka innych przydatnych argumentów za dumpdata :

• --indent=4 uczynić go czytelnym dla człowieka.
• -e sessions wykluczyć dane sesji
• -e admin wykluczyć historię działań administratora na stronie administratora
• -e contenttypes -e auth.Permissionwykluczyć obiekty, które są automatycznie odtwarzane ze schematu za każdym razem w trakcie syncdb. Używaj go tylko razem z, w --naturalprzeciwnym razie możesz skończyć ze źle dopasowanymi numerami identyfikacyjnymi.

Tak, to naprawdę irytujące. Przez chwilę omijałem to, wykonując „manage.py reset” w aplikacji contenttypes przed załadowaniem urządzenia (aby pozbyć się automatycznie generowanych danych contenttypes, które różniły się od zrzuconej wersji). To zadziałało, ale w końcu miałem dość kłopotów i całkowicie porzuciłem urządzenia na rzecz prostych zrzutów SQL (oczywiście, wtedy tracisz przenośność DB).

aktualizacja - najlepszą odpowiedzią jest użycie --naturalflagi dumpdata, zgodnie z poniższą odpowiedzią. Ta flaga jeszcze nie istniała, kiedy pisałem tę odpowiedź.

Spróbuj pominąć typy zawartości podczas tworzenia urządzenia:

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

U mnie zadziałało w podobnej sytuacji w przypadku testów jednostkowych, Twój wgląd w typy zawartości naprawdę pomógł!

Odpowiedzi tutaj wszystkie stare ... Od 2017 roku najlepszą odpowiedzią jest:

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

Nie używałem MySQL, ale zamiast tego importowałem niektóre dane z aktywnego serwera do sqlite. Wyczyszczenie contenttypesdanych aplikacji przed wykonaniem loaddatazałatwiło sprawę:

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

I wtedy

python manage.py loaddata data.json

Rozwiązałem ten problem w moich przypadkach testowych, resetując aplikację contenttypes z testu jednostkowego przed załadowaniem pliku zrzutu. Carl zasugerował to już przy użyciu manage.pypolecenia, a ja robię to samo tylko call_commandmetodą:

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

Moje full_test_data.jsonurządzenie zawiera zrzut aplikacji contenttypes, który odpowiada pozostałym danym testowym. Resetowanie aplikacji przed załadowaniem zapobiega zduplikowaniu klucza IntegrityError.

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

To działa dla mnie. Tutaj wykluczam wszystko, co dotyczy rzeczywistych modeli.

• Jeśli zobaczysz inny model niż modele, które utworzyłeś, możesz je bezpiecznie wykluczyć. Jedną z wad tego podejścia jest utrata danych dziennika, a także danych uwierzytelniania.

Aby przedstawić dowolny klucz obcy i relacje „wiele do wielu”, należy użyć kluczy naturalnych. Ponadto dobrym pomysłem może być wykluczenie sessiontabeli w sessionsaplikacji i logentrytabeli w adminaplikacji.

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

Zgodnie z dokumentacją Django , --naturalzostał wycofany w wersji 1.7, więc --natural-foreignzamiast tego należy użyć tej opcji .

Możesz również pominąć klucz podstawowy w zserializowanych danych tego obiektu, ponieważ można go obliczyć podczas deserializacji, przekazując --natural-primaryflagę.

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

ulegnie zmianie

  "content_type": 123

do

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

A urządzenie na TestCaserazie działa

Django 2.2.5

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

pomogło mi

Podam inną możliwą odpowiedź, którą właśnie odkryłem. Może to pomoże OP, może pomoże komuś innemu.

Mam tabelę relacji wiele do wielu. Ma klucz podstawowy i dwa klucze obce do innych tabel. Stwierdziłem, że jeśli mam wpis w urządzeniu, którego dwa klucze obce są takie same jak inny wpis już w tablicy z innym pakietem, zakończy się niepowodzeniem. Tabele relacji M2M mają „unikalne razem” dla dwóch kluczy obcych.

Tak więc, jeśli jest to relacja M2M, która się zrywa, spójrz na dodawane klucze obce, spójrz na swoją bazę danych, aby zobaczyć, czy ta para FK jest już wymieniona pod inną PK.

To naprawdę irytujące… Za każdym razem mnie to ugryza.

Próbowałem zrzucić dane z --exclude contenttypes i --natural, zawsze mam problemy.

To, co działa najlepiej, to po prostu wykonanie pliku truncate table django_content_type; po synchronizacji, a NASTĘPNIE załadowanie danych.

Oczywiście dla automatycznego ładowania initial_data.json jesteś fallball.

Czasami napotkałem podobny błąd. Okazało się, że próbowałem załadować urządzenia przed utworzeniem niezbędnych tabel. Więc zrobiłem:

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

I działało jak urok

W moim przypadku zrzuciłem dane z auth(./manage.py dumpddata auth > fixtures/auth.json ), aby użyć urządzenia do celów testowych.

Rozwój był kontynuowany i usunąłem większość modeli, które zdefiniowałem w models.py i wtedy zacząłem widzieć ten irytujący problem.

Moim rozwiązaniem było ponowne zregenerowanie urządzenia auth.json. Ten usunął wiele wpisów auth.permissionzwiązanych ze starymi modelami, które miałem.

Próbowałem każdej metody z góry, nic nie działało dla mnie. Muszę wykluczyć pełny model uwierzytelniania i działa dobrze.

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