Проблемы с contenttypes при загрузке прибора в Django

Ответ 1

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, иначе вы можете столкнуться с плохо выровненными номерами идентификаторов.

Ответ 2

Да, это действительно раздражает. Некоторое время я работал над ним, выполняя "manage.py reset" в приложении contenttypes перед загрузкой прибора (чтобы избавиться от автоматически генерируемых данных контента, которые отличались от сбрасываемой версии). Это сработало, но в итоге я устал от неприятностей и оставленных светильников полностью в пользу прямых SQL-дампов (конечно, тогда вы теряете переносимость DB).

update - лучший ответ - использовать флаг --natural для dumpdata, как указано в ответе ниже. Этот флаг еще не существовал, когда я написал этот ответ.

Ответ 3

Попробуйте пропустить типы контента при создании привязки:

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

Это работало для меня в аналогичной ситуации для модульных тестов, вам очень помогло понимание про контент-типов!

Ответ 4

Ответы здесь все старые... По состоянию на 2017 год лучший ответ:

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

Ответ 5

Я не использовал MySQL, но вместо этого импортировал некоторые данные с живого сервера в sqlite. Очистка данных приложения contenttypes перед выполнением loaddata сделала трюк:

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

И затем

python manage.py loaddata data.json

Ответ 6

Я разрешил эту проблему в своих тестовых случаях, сбросив приложение contenttypes из unit test до загрузки файла дампа. Карл предложил это уже с помощью команды 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)

My full_test_data.json fixture содержит дамп приложения контента, который соответствует остальным тестовым данным. Сбрасывая приложение перед загрузкой, он предотвращает дублирование ключа IntegrityError.

Ответ 7

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

Это работает для меня. Здесь я исключаю все пузырьки реальных моделей.

• Если вы видите какую-либо другую модель, отличную от созданных вами моделей, вы можете смело исключить их. Одним из недостатков этого подхода является то, что вы теряете данные журнала, а также данные auth.

Ответ 8

Вы должны использовать естественные ключи для представления любых внешних ключей и отношений "многие ко многим". Кроме того, может быть хорошей идеей исключить таблицу session в приложении sessions и таблицу logentry в приложение admin.

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

Согласно документации Django, --natural устарел в версии 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

Ответ 9

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

изменится

  "content_type": 123

в

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

И крепление работает для TestCase сейчас

Ответ 10

Я собираюсь дать еще один возможный ответ, который я только что понял. Может быть, это поможет OP, может быть, это поможет кому-то еще.

У меня есть таблица отношений "многие ко многим". Он имеет первичный ключ и два внешних ключа к другим таблицам. Я обнаружил, что если у меня есть запись в приборе, у которых два внешних ключа совпадают с другой записью, уже находящейся в таблице с другим pk, это не сработает. Таблицы отношений M2M имеют "уникальную комбинацию" для двух внешних ключей.

Итак, если это нарушение отношения M2M, посмотрите на внешние ключи, которые он добавляет, посмотрите на свою базу данных, чтобы увидеть, что эта пара FK уже указана в разных PK.

Ответ 11

Это действительно, очень раздражает.. Я укусаюсь этим каждый раз.

Я попытался создать dumpdata с --exclude contenttypes и --естественно, я всегда получаю проблемы.

Что лучше всего подходит для меня, просто выполняйте truncate table django_content_type; после syncdb и THEN загружайте данные.

Конечно, для автозагрузки initial_data.json вы являетесь fallball.

Ответ 12

Я иногда сталкивался с подобной ошибкой. Оказалось, что я пытался загрузить приборы, прежде чем создавать необходимые таблицы. Итак, я сделал:

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

И он работал как шарм

Ответ 13

Джанго 2.2.5

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

это помогло мне