Urządzenia django (z dumpdata) uległy awarii podczas testowania

Question

Próbuję zrzucić dane z mojego serwera produkcyjnego do użycia jako test na moim serwerze dev, ale dostaję błędy podczas uruchamiania "testu ./manage.py" na serwer dev określający plik urządzenia utworzony na serwerze prod.

Oto stara zrobiłem w oparciu o Google Search/stackoverflow:

# python manage.py dumpdata --indent=4 --natural 
error when running tests: IntegrityError: (1062, "Duplicate entry 'cms-agencies' for key 'app_label'") 

# python manage.py dumpdata --exclude contenttypes --indent=4 
error when running tests: IntegrityError: (1452, 'Cannot add or update a child row: a foreign key constraint fails (`test_current`.`django_admin_log`, CONSTRAINT `content_type_id_refs_id_288599e6` FOREIGN KEY (`content_type_id`) REFERENCES `django_content_type` (`id`))') 

# python manage.py dumpdata --exclude contenttypes --natural --indent=4 
error when running tests: IntegrityError: (1062, "Duplicate entry '14-add_agencies' for key 'content_type_id'") 

# python manage.py dumpdata --exclude contenttypes --exclude auth --indent=4 
error when running tests: IntegrityError: (1452, 'Cannot add or update a child row: a foreign key constraint fails (`test_current`.`django_admin_log`, CONSTRAINT `user_id_refs_id_c8665aa` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`))') 

# python manage.py dumpdata --exclude contenttypes --exclude auth --natural --indent=4 
error when running tests: IntegrityError: (1452, 'Cannot add or update a child row: a foreign key constraint fails (`test_current_abril`.`django_admin_log`, CONSTRAINT `user_id_refs_id_c8665aa` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`))') 

Próbowałem też usuwając " 'init_command': 'SET storage_engine = InnoDB" od settings.py i wciąż mam 1062 błędów.

Nie rozumiem tego problemu. Czy nie powinienem django odtworzyć bazy danych dokładnie tak, jak było to na serwerze prod, kiedy ładuję urządzenia?

Answer 1

Wierzę, że błędy mówią dokładnie, co się dzieje. Czy app_label jest unikatowy? Zgaduję, że tak. Sądzę, że masz dwa obiekty o tej samej wartości klucza app_label. (cms-agencies)

Dodatkowo, gdy masz relację klucza obcego, musisz mieć obiekt, który odpowiada kluczowi obcemu. Dump data nie robi tego, ponieważ zrzuca tylko jeden model.

Coś jak https://github.com/davedash/django-fixture-magic jest świetny do tego. Zrzuca on model i wszystkie zależności fk.

Answer 2

miałem podobne problemy i te args pracował dla mnie:

python manage.py dumpdata --natural --exclude auth.permission --exclude contenttypes --indent 4 

ja też miałem wiele problemów z sygnałem post_save tworzenia obiektów dwukrotnie. Jest na to poprawka: How do I prevent fixtures from conflicting with django post_save signal code?

Answer 3

Twoim problemem może być wyrzucenie pliku unicode, ale django spodziewa się pliku w formacie ASCII podczas ładowania. Stanie się tak przy użyciu PowerShell w systemie Windows, jeśli dotyczy to Ciebie.

Answer 4

Problem polega na tym, że jeśli użyjesz kluczy naturalnych (kluczy naturalnych i obcych w późniejszych wersjach Django), Django będzie przechowywać relacje wiele-do-wielu w obiektach-rodzicach. To jest coś, co chcesz. Ale nie można po prostu zrzucić wszystkich tabel, nie wolno uwzględniać tabel/modeli wielu do wielu, ponieważ wtedy można załadować te same dane dwukrotnie - oraz bum, duplikaty i IntegrityErrors.

Na przykład, należy zrzucić auth.User i auth.Group, ale nie auth.User_Groups. Spójrz na przykład na wysypisko z Django 1.7:

{ 
    "model": "auth.group", 
    "fields": { 
     "permissions": [], 
     "name": "ST" 
    }, 
}, 
{ 
    "model": "auth.group", 
    "fields": { 
     "permissions": [], 
     "name": "property_manager" 
    }, 
}, 

{ 
    "model": "auth.user", 
    "fields": { 
     "username": "boss", 
     "groups": [ 
      ["property_manager"],["ST"], 
     ], 
     "user_permissions": [], 
    }, 
}, 

Po linia tworzy kompleksową zrzut użytkowników/uprawnień i typów zawartości można przenieść do dev aby uzyskać identyczną kopię, włączając w identycznej kolejności wierszy i kluczy podstawowych (testowane na Django 1.7):

python manage.py dumpdata auth.User auth.Group contenttypes auth.Permission --indent 4 --natural-foreign > users.json