Django에서 고정 장치를 로드할 때 내용 유형에 문제가 있습니다.

Django에서 고정 장치를 로드할 때 내용 유형에 문제가 있습니다.

콘텐츠 유형이 충돌하여 MySQL 데이터베이스에 Django 고정장치를 로드하는 데 문제가 있습니다.처음에는 이렇게 앱에서만 데이터를 덤프하려고 했습니다.

./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 에서 문서화되어 있는 버그와 같은 것으로 보입니다.

문제는 이미 하고 있는 content types 앱을 덤프하는 것이 권장되는 회피책이라는 것입니다!?왜 그러고 있어?차이가 있는 경우는, 다음의 문서에 기재되어 있는 커스텀 모델 권한을 가지고 있습니다.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 session data(세션 제외)
• -e admin 을 제외합니다.
• -e contenttypes -e auth.Permission에서 syncdb와 함께 하는 것은 .와 함께 사용할 수 .--natural그렇지 않으면 ID 번호가 잘못 정렬될 수 있습니다.

해답은 다 낡아서...2017년 현재 최선의 답은 다음과 같습니다.

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

네, 이거 정말 짜증나요.한동안 '매니지'를 하면서 일을 했어요.py reset"을 클릭합니다(덤프된 버전과 다른 자동으로 생성된 콘텐츠 유형 데이터를 제거합니다).하지만 결국 번거로움과 버려진 고정장치가 지겨워져서 SQL 덤프를 그대로 사용할 수 없게 되었습니다(물론 DB 이식성을 잃게 됩니다).

update - 가장 좋은 답은 다음과 같습니다.--natural을 들다dumpdata(미국의)내가 이 답을 썼을 때 그 깃발은 아직 존재하지 않았다.

고정 장치를 만들 때 내용 유형을 건너뜁니다.

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

유닛 테스트에서도 비슷한 상황에서 효과가 있었습니다.콘텐츠 타입에 대한 당신의 통찰이 큰 도움이 되었습니다!

MySQL을 사용하지 않고 라이브 서버에서 sqlite로 데이터를 가져왔습니다.「」의 contenttypes 전 앱 loaddata요령을 부렸다.

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

그리고 나서.

python manage.py loaddata data.json

덤프 파일을 로드하기 전에 유닛 테스트에서 content types 앱을 리셋하여 테스트 케이스에서 이 문제를 해결했습니다.을 했습니다.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.json 부분에 가 포함되어 있습니다.contenttype contenttype contenttype contenttype은 contenttype으로 되어 있습니다.으로써 키 할 수 있습니다.IntegrityError.

외부 키 및 다대다 관계를 나타내려면 자연 키를 사용해야 합니다. 이 경우, 이 경우 수 .session의 표sessions과 '앱'을 합니다.logentry의 표admindiscloss.

장고 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되지 않기 "1.7"은 "" 입니다.--natural-foreign대신 사용해야 합니다.

또, 이의 시리얼화된 키를 할 수도 있습니다.은, 이 는, 에 「프라이머리 키」를 할 수 때문입니다.이것은, 디시리얼라이제이션중에 프라이머리 키를 계산할 수 있기 때문입니다.--natural-primary

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

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

난 이거면 돼.여기에서는 실제 모델의 모든 것을 제외합니다.

• 생성한 모델 외에 다른 모델이 있는 경우 해당 모델을 제외할 수 있습니다.이 접근법의 한 가지 단점은 인증 데이터뿐만 아니라 로그 데이터도 느슨하다는 것입니다.

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

변화할 것이다

  "content_type": 123

로.

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

★★★★★★★★★★★★★★★★★★★★★★★★★★★★TestCase이쯤에서

정말, 정말 짜증나..매번 이런 거에 물릴 때마다.

--exclude content types 및 --natural로 데이터를 덤프하려고 하면 항상 문제가 발생합니다.

잘 맞는 '일부러'를 이다.truncate table django_content_type; 후 syncdb를 합니다.

물론 initial_data.json의 자동 로딩에 대해서는 매우 매력적입니다.

장고 2.2.5

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

그것은 나에게 도움이 되었다

제가 방금 알아낸 답을 하나 더 드리겠습니다.작전에도 도움이 될 수 있고 다른 사람에게도 도움이 될 수 있어

난 다대다 관계표를 가지고 있어.여기에는 프라이머리 키와 다른 테이블에 대한2개의 외부 키가 있습니다.다른 pk를 가진 테이블에 이미 있는 다른 엔트리와 동일한 외부 키가 있는 엔트리가 픽스쳐에 있는 경우 해당 엔트리는 실패합니다.M2M 관계 테이블에는 2개의 외부 키에 대해 "일관"이 있습니다.

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

저는 예전에 비슷한 오류를 겪었습니다.알고 보니 필요한 테이블을 만들기 전에 고정 장치를 장착하려고 했습니다.그래서 나는 했다:

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

그리고 그것은 마법처럼 작용했다.

위에서 온갖 방법을 다 써봤지만 아무 것도 통하지 않았어완전한 인증 모델을 제외해야 하고 정상적으로 작동합니다.

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

내 경우엔, 난 그 데이터를 버렸어auth(./manage.py dumpddata auth > fixtures/auth.json)를 사용하여 테스트합니다.

개발은 계속되었고, 저는 제가 정의한 대부분의 모델을 제거했습니다.models.py이 귀찮은 문제가 보이기 시작한 건 이때부터예요.

제 솔루션은 auth.json 고정장치를 다시 생성하는 것이었습니다.이것은 많은 엔트리를 삭제했습니다.auth.permission예전 모델들과 관련이 있어요.

테스트 셋업과 티어다운을 추가하여 이 문제를 해결했습니다.

from django.core import management

=====

def setUp(self):
    management.call_command("loaddata", "all-data.yaml", verbosity=0)
    super(login_page_test, self).setUp()

def tearDown(self):
    management.call_command("flush", verbosity=0, interactive=False)
    super(login_page_test, self).setUp()

언급URL : https://stackoverflow.com/questions/853796/problems-with-contenttypes-when-loading-a-fixture-in-django