Django column "name" отношения "django_content_type" не существует

Ответ 1

Обнаружено это при обновлении до 1,8 и миграции из MySQL в Postgres.

Я не могу объяснить, почему возникает ошибка, но мне удалось обойти это, вручную добавив столбец:

• Удалить все миграции

• Удалить записи из django_migrations

• Вручную добавьте столбец name:

  ALTER TABLE django_content_type ADD COLUMN name character varying(50) NOT NULL DEFAULT 'someName';
  

• Запустить поддельный начальный: $ python manage.py migrate --fake-initial

Редактировать 12/2016. Я рекомендую это как обходной путь, более подходящий для личных проектов или локальных сред, а не для производственных сред. Очевидно, что если вы заботитесь о своей истории миграции, это не путь.

Ответ 2

Сегодня я столкнулся с той же проблемой, и хотел бы добавить краткий обзор проблемы и ее решение:

Источник проблемы:

Django 1.8 изменил свои внутренние структуры базы данных, а столбец name больше не существует в базе данных (см. взято из атрибута verbose_name модель).

Чтобы это сделать, автоматически создается миграция contenttypes - 0002_remove_content_type_name.

Обычно все ваши миграции должны быть применены, и это должно быть записано в таблице django_migrations, и все должно быть хорошо.

Если вы, например, сделали резервную копию своей базы данных с помощью dumpdata, очистили (сбросили) все содержимое базы данных и загрузили дамп с помощью loaddata, ваша таблица django_migrations останется пустой.

Таким образом, migrate пытается снова применить все миграции (даже если ваши таблицы уже существуют), и он не работает, когда пытается удалить несуществующий столбец name.

Вы можете проверить, применима ли эта ситуация, либо проверив таблицу django_migrations, либо - гораздо более удобную - запустив python manage.py showmigrations. Если ваша ситуация выглядит как

contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name

вы в порядке (или на самом деле у вас другая проблема), если это выглядит как

contenttypes
 [ ] 0001_initial
 [ ] 0002_remove_content_type_name

вы столкнулись с ситуацией, описанной выше. Пожалуйста, дважды проверьте, что ваша база данных содержит все таблицы и все столбцы (за исключением изменений, которые вы хотели применить при неудачной миграции).

Что делать/шаг за шагом Решение:

Итак, наша структура базы данных в порядке (за исключением изменений, которые вы хотели применить при неудачной миграции), но Django/migrate просто не знает об этом. Поэтому давайте сделаем что-нибудь об этом:

• Скажите Django, что все миграции contenttypes были применены: manage.py migrate --fake contenttypes. Если вы хотите дважды проверить, запустите showmigrations.

• Не указывать Django, что все миграции до того, который вы хотите применить, были применены. Для этого вам потребуется номер миграции, как показано на рисунке showmigrations. Например, если ваша ситуация выглядит как

  my_app
   [ ] 0001_initial
   [ ] 0002_auto_20160616_0713
  

  и ваш migrate не удалось при использовании 0002_auto_20160616_0713, последний успешно примененный перенос в вашей базе данных был 0001_initial. Затем Wen применяет запись в django_migrations -table на python manage.py migrate --fake my_app 0001 (помните, что количество миграций достаточно). migrate автоматически подделывает все другие зависимые миграции, если это необходимо.

• Теперь мы можем применить миграцию missiong, и на этот раз нам нужно сделать это по-настоящему и не подделано! Итак, мы запускаем python manage.py migrate my_app. Это должно изменить базу данных по мере необходимости.

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

• Двойная проверка и очистка: снова используйте showmigrations, чтобы проверить, было ли применено все миграции. Если есть открытые миграции, подделайте их, используя python manage.py migrate --fake.

Вещи, которые вы не должны делать

• удалить все миграции - в производственном параметре это может быть просто неприменимо, поскольку они могут содержать некоторую работу для переноса данных, которые не должны быть потеряны.
• вручную добавить столбец name в contenttypes - он будет удален после применения миграции. Хорошо, это рабочий хак, но он не адресует проблему.

Что вы должны делать

Попытайтесь выяснить, как вы попали в эту ситуацию, и найти способы избежать этого.

Моя проблема заключалась в том, что у меня были разные базы данных для моего проекта (sqlite для быстрого тестирования разработки, локальные postgres для тестирования в реальном мире, удаленные постгрессы для производства), и я хотел копировать контент из одного в другой.

Ответ 3

Я получал эту ошибку после того, как мы решили удалить миграции из управления версиями (git) и создать новую базу данных с нуля.

Что-то, что сработало для меня (хотя, честно говоря, я не уверен, почему) было запускать "makemigrations" для каждого приложения. так что "python manage.py makemigrations app1", "python manage.py makemigrations app2" и т.д. для каждого приложения Django.

Наконец, я просто запускал "python manage.py migrate", пересек мои пальцы, и это сработало.

Любое понимание того, как и почему это сработало, было бы полезно.

Ответ 4

Я знаю, что это старый вопрос, но это может помочь кому-то. Я тоже получал эту ошибку. Проблема заключалась в том, что content_types имела миграцию с именем 0002_remove_content_type_name, которая удаляет столбец "имя".
После удаления данных миграции из таблицы и папки эти шаги работают для меня:

./manage.py makemigrations myappname
./manage.py migrate myappname
./manage.py migrate --fake contenttypes

Если вы уверены, что остальная часть вашего db отражает вашу миграцию, вы можете использовать:

./manage.py migrate --fake

Смотрите результат:

./manage.py showmigrations

После этого все ваши миграции должны быть отмечены, и вы должны быть в порядке

Ответ 5

У меня была та же проблема, но я смог ее решить, добавив это в мои зависимости миграции:

('contenttypes', '0002_remove_content_type_name')

Надеюсь, что это поможет!

Ответ 6

Другим вариантом, который работал у меня (из пустой базы данных), был:

./manage.py makemigrations myappname
./manage.py migrate

Вариант, который НЕ работает:

./manage.py makemigrations myappname
./manage.py migrate myappname

Или, скорее, последовательность, по-видимому, будет работать в первый раз, но не будет работать во второй раз, жалуясь, что django_content_type не существует.

Рабочий (первый 2-строчный) вариант выше, кажется, идемпотентен.

(отредактировано: для удаления избыточной второй строки из исходной 3-строчной рабочей версии)