Django에서 조명기를로드 할 때 컨텐츠 유형 문제

콘텐츠 유형 충돌로 인해 Django 고정 장치를 MySQL 데이터베이스에로드하는 데 문제가 있습니다. 먼저 다음과 같이 내 앱에서만 데이터를 덤프하려고했습니다.

./manage.py dumpdata escola > fixture.json

하지만 내 앱 "escola"가 다른 응용 프로그램의 테이블을 사용하기 때문에 외래 키 문제가 계속 누락되었습니다. 나는 이것을 얻을 때까지 추가 앱을 계속 추가했습니다.

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

이제 문제는 데이터를 테스트 픽스처로로드하려고 할 때 다음과 같은 제약 조건 위반입니다.

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

문제는 Django가 조명기의 기본 키 값과 충돌하는 다른 기본 키 값을 사용하여 콘텐츠 유형을 동적으로 다시 만들려고한다는 것입니다. 이것은 http://code.djangoproject.com/ticket/7052에 문서화 된 버그와 동일한 것으로 보입니다 .

문제는 권장되는 해결 방법이 이미 수행중인 콘텐츠 유형 앱을 덤프하는 것입니다!? 무엇을 제공합니까? 차이가 나는 경우 http://docs.djangoproject.com/en/dev/ref/models/options/#permissions에 설명 된대로 사용자 지정 모델 권한이 있습니다.

manage.py dumpdata --natural더 내구성있는 외래 키 표현을 사용합니다. 장고에서는 "자연 키"라고 부릅니다. 예를 들면 :

• Permission.codename 찬성하여 사용 Permission.id
• User.username 찬성하여 사용 User.id

더 읽기 : "django 객체 직렬화"의 자연 키 섹션

다음에 대한 다른 유용한 인수 dumpdata:

• --indent=4 사람이 읽을 수 있도록합니다.
• -e sessions 세션 데이터 제외
• -e admin 관리 사이트의 관리 작업 기록 제외
• -e contenttypes -e auth.Permission동안 매번 스키마에서 자동으로 다시 생성되는 개체를 제외합니다 syncdb. 함께 사용하지 --natural않으면 ID 번호가 잘못 정렬 될 수 있습니다.

네, 정말 짜증이납니다. 잠시 동안 고정기를로드하기 전에 contenttypes 앱에서 "manage.py 재설정"을 수행하여 문제를 해결했습니다 (덤프 된 버전과 다른 자동 생성 된 contenttypes 데이터를 제거하기 위해). 그것은 효과가 있었지만 결국 나는 번거 로움에 질려서 직선 SQL 덤프를 위해 전적으로 비품을 포기했습니다 (물론 DB 이식성을 잃습니다).

update- 가장 좋은 대답은 아래 답변에 명시된 것처럼 --natural플래그를 사용 dumpdata하는 것입니다. 이 답변을 썼을 때 그 깃발은 아직 존재하지 않았습니다.

고정물을 만들 때 콘텐츠 유형을 건너 뛰십시오.

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

단위 테스트와 비슷한 상황에서 저에게 효과적이었습니다. 콘텐츠 유형에 대한 귀하의 통찰력이 정말 도움이되었습니다!

여기에 대한 답변은 모두 오래된 것입니다 ... 2017 년 현재 가장 좋은 답변은 다음과 같습니다.

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

나는 MySQL을 사용하지 않고 대신 라이브 서버에서 sqlite로 일부 데이터를 가져 왔습니다. contenttypes수행하기 전에 앱 데이터를 지우면 loaddata트릭이 발생했습니다.

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

그리고

python manage.py loaddata data.json

내 덤프 파일을로드하기 전에 단위 테스트에서 contenttypes 앱을 재설정하여 테스트 사례에서이 문제를 해결했습니다. Carl은 이미 manage.py명령을 사용하여 이것을 제안 했으며 call_command방법을 사용해서 만 동일한 작업을 수행합니다 .

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

내 full_test_data.jsonFixture에는 나머지 테스트 데이터에 해당하는 contenttypes 앱 덤프가 포함되어 있습니다. 로드하기 전에 앱을 재설정하여 중복 키를 방지합니다 IntegrityError.

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

이것은 나를 위해 작동합니다. 여기에서는 실제 모델의 모든 것을 제외하고 있습니다.

• 생성 한 모델 이외의 다른 모델이 표시되면 안전하게 제외 할 수 있습니다. 이 접근 방식의 한 가지 단점은 인증 데이터뿐만 아니라 로그 데이터가 느슨하다는 것입니다.

외래 키와 다 대다 관계를 나타내려면 자연 키를 사용해야합니다. 또한 앱의 테이블 과 앱 의 session테이블 을 제외하는 것이 좋습니다 .sessionslogentryadmin

Django 1.7 이상

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

장고 <1.7

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

에 따르면 장고 문서 , --natural옵션이 있으므로, 버전 1.7에서 사용되지 않으며 --natural-foreign대신 사용해야합니다.

--natural-primary플래그 를 전달하여 deserialization 중에 계산할 수 있으므로이 개체의 직렬화 된 데이터에서 기본 키를 생략 할 수도 있습니다 .

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

바뀔 것이다

  "content_type": 123

에

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

그리고 고정물은 TestCase현재 작동합니다.

장고 2.2.5

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

그것은 나를 도왔다

방금 알아 낸 또 다른 가능한 답을 드리겠습니다. OP에 도움이 될 수도 있고 다른 사람에게 도움이 될 수도 있습니다.

다 대다 관계 테이블이 있습니다. 기본 키와 다른 테이블에 대한 두 개의 외래 키가 있습니다. 두 개의 외래 키가 이미 다른 pk를 가진 테이블에있는 다른 항목과 동일한 조명기에 항목이 있으면 실패합니다. M2M 관계 테이블은 두 개의 외래 키에 대해 "함께 고유"합니다.

따라서 중단되는 M2M 관계인 경우 추가하는 외래 키를 확인하고 데이터베이스에서 해당 FK 쌍이 이미 다른 PK 아래에 나열되어 있는지 확인합니다.

정말 짜증나 .. 매번 이것에 물린다.

--exclude contenttypes 및 --natural로 데이터를 덤프하려고했지만 항상 문제가 발생합니다 ..

나에게 가장 적합한 것은 단순히 truncate table django_content_type;syncdb 후 데이터를로드 한 후 수행하는 것입니다.

물론 initial_data.json 자동로드의 경우 폴볼입니다.

나는 때때로 전에 비슷한 오류가 발생했습니다. 필요한 테이블을 만들기 전에 고정물을로드하려고했습니다. 그래서 나는 :

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

그리고 그것은 매력처럼 작동했습니다.

제 경우에는 테스트 목적으로 고정물을 사용하기 위해 auth( ./manage.py dumpddata auth > fixtures/auth.json) 에서 데이터를 덤프했습니다 .

개발은 계속되었고 내가 정의했던 대부분의 모델을 제거했고 models.py, 이때이 성가신 문제를보기 시작했습니다.

내 솔루션은 auth.json 고정 장치를 다시 생성했습니다. 이것은 auth.permission내가 가지고 있던 오래된 모델과 관련된 많은 항목을 제거했습니다 .

나는 위에서 모든 방법을 시도했지만 아무것도 효과가 없었습니다. 완전한 인증 모델을 제외하고 잘 작동합니다.

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