Django.db.migrations.exceptions.InconsistentMigrationHistory

Ответ 1

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

Вы должны усечь таблицу django_migrations из своей базы данных, а затем попробуйте снова применить миграции. Он должен работать, но если он не запускает makemigrations снова, а затем мигрирует.

Примечание. Не забудьте взять резервную копию своих данных.

Ответ 2

Прежде всего удалите все таблицы из базы данных, удалите все файлы из папки миграции, кроме __init__.py, затем запустите migrate.

Ответ 3

Поскольку вы используете пользовательскую модель пользователя, вы можете сначала прокомментировать

INSTALLED_APPS = [
...
#‘django.contrib.admin’,
...
]

в настройках Installed_Apps. Затем запустите

python manage.py migrate.

Когда закончите раскомментировать

‘django.contrib.admin’.

Ответ 4

Давайте начнем с решения проблемы с большинством ответов на этой странице:

Вам никогда не придется удалять свою базу данных, если вы правильно используете систему миграции Django, и вам никогда не следует удалять миграции после их завершения

Теперь лучшее решение для вас зависит от ряда факторов, которые включают в себя ваш опыт работы с Django, уровень вашего понимания системы миграции и ценность данных в вашей базе данных.

Короче говоря, есть два способа устранения любой ошибки миграции.

1. Возьми ядерный вариант. Предупреждение: это только вариант, если вы работаете в одиночку. Если другие люди зависят от существующих миграций, вы не можете просто удалить их.

   • Удалите все ваши миграции и восстановите новый набор с помощью python3 -m manage makemigrations. Это должно устранить любые проблемы с зависимостями или несоответствиями в ваших миграциях.
   • Оставьте всю свою базу данных. Это устранит все проблемы, которые у вас были с несоответствиями между вашей фактической схемой базы данных и схемой, которую вы должны были основать на истории миграции, и устранит все проблемы, которые у вас возникли с несоответствиями между вашей историей миграции и вашими предыдущими файлами миграции [вот что InconsistentMigrationHistory жалуется].
   • Создайте заново схему базы данных с помощью python3 -m manage migrate

2. Определите причину ошибки и устраните ее, потому что (если судить по опыту) причина почти наверняка является чем-то глупым, что вы сделали. (Как правило, из-за непонимания того, как правильно использовать систему миграции). На основании ошибки, которую я вызвал, есть три категории.

   1. Несоответствия с файлами миграции. Это довольно распространенный случай, когда над проектом работают несколько человек. Надеемся, что ваши изменения не конфликтуют, и makemigrations --merge может решить эту проблему, в противном случае кому-то придется откатить свои миграции до точки ветвления, чтобы решить эту проблему.
   2. Несоответствия между вашей схемой и историей миграции. Для этого кто-то должен был отредактировать схему базы данных вручную или удалить миграции. Если они удалили миграцию, отмените свои изменения и кричите на них; Вы никогда не должны удалять миграции, если другие зависят от них. Если они отредактировали схему базы данных вручную, отмените их изменения и затем кричите на них; Джанго управляет схемой базы данных, никто другой.
   3. Несоответствия между вашей историей миграции и вашими файлами миграции. [Это проблема InconsistentMigrationHistory, от которой страдает спрашивающий, и та, от которой я страдал, когда попал на эту страницу]. Чтобы справиться с этим, кто-то либо вручную испортил таблицу django_migrations, либо удалил миграцию после ее применения. Чтобы решить эту проблему, вам нужно будет выяснить, как возникло несоответствие, и вручную устранить его. Если ваша схема базы данных правильная, и это просто ваша история миграции, вы можете вручную отредактировать таблицу django_migrations, чтобы решить эту проблему. Если ваша схема базы данных неверна, вам также придется вручную отредактировать ее, чтобы привести ее в соответствие с тем, чем она должна быть.

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

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

Поверьте, вы можете исправить эту ошибку, не став ядерным!

Ответ 5

Вот как это правильно решить.

Выполните следующие действия в папке миграций внутри проекта:

1. Удалите файлы _pycache_ и 0001_initial.
2. Удалите db.sqlite3 из корневого каталога (будьте осторожны, все ваши данные исчезнут).
3. на терминале запустить:
   1. python manage.py makemigrations
      python manage.py перенести

Вуаля.

Ответ 6

проблема

django.db.migrations.exceptions.InconsistentMigrationHistory: миграция admin.0001_initial применяется до его учетной записи зависимости.0001_initial для базы данных "по умолчанию".

Таким образом, мы можем сначала перенести базу данных без администратора (admin.0001_initial).

После миграции зависимостей выполните команды для миграции admin.0001_initial.

Решение

1. удалите 'django.contrib.admin' из INSTALLED_APPS в settings.py.
2. выполнить команды:

Python manage.py makemigrations имя приложения

Python manage.py перенести имя приложения

3. добавьте 'django.contrib.admin' в INSTALLED_APPS в файле settings.py.
4. выполнить команды еще раз:

$: Python manage.py makemigrations имя приложения

$: Python manage.py перенести имя приложения

Ответ 7

Это произошло со мной в новом проекте после того, как я добавил пользовательскую модель User согласно рекомендации в django docs.

Если вы начинаете новый проект, настоятельно рекомендуется настроить пользовательскую модель пользователя, даже если вам достаточно модели пользователя по умолчанию.

Вот что я сделал, чтобы решить проблему.

1. Удалить базу данных db.sqlite3.
2. Удалите папку приложения/миграции.

За @jackson, временно закомментируйте django.contrib.admin.

INSTALLED_APPS = [
...
#‘django.contrib.admin,
...
]

Также закомментируйте администратор сайта в urls.py:

urlpatterns = [
    path('profile/', include('restapp.urls')),
    #path('admin/', admin.site.urls),
]

Если вы не закомментируете путь ('admin/'), вы получите сообщение об ошибке "LookupError: не установлено приложение с меткой" admin "" при запуске

python manage.py migrate

После завершения миграции раскомментируйте оба перечисленных выше варианта.

Ответ 8

просто удалите файл sqlite или запустите flush для базы данных "python manage.py flush", а затем выполните команды makemigrations и migrate соответственно.

Ответ 9

когда вы создаете новый проект Django и запускаете

Python manage.py мигрировать

Django создаст для вас 10 таблиц по умолчанию, включая одну таблицу auth_user и две, начинающиеся с auth_user.

когда вы хотите создать пользовательскую модель, наследуемую от AbstractUser, вы столкнетесь с этой проблемой с сообщением об ошибке следующим образом:

django.db.migrations.exceptions.InconsistentMigrationHistory: Migration admin.0001_initial is applied before its dependency account.0001_initial on database 'default'.

Я решаю эту проблему, отбрасывая всю свою базу данных, и создаю новую. И это заменило три таблицы, которые я упомянул.

Ответ 10

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

$ ./manage.py migrate account

А потом:

$ ./manage.py migrate

Ответ 11

Если вы установите AUTH_USER_MODE L в settings.py следующим образом:

AUTH_USER_MODEL = 'custom_user_app_name.User'

Вы должны прокомментировать эту строку перед запуском команд makemigration и migrate. Затем вы можете снова раскомментировать эту строку.

Ответ 12

когда вы создаете новый проект без приложений, вы запускаете

python manage.py migrate

Django создаст 10 таблиц по умолчанию.

Если вы хотите создать пользовательскую модель клиента, которая наследуется от AbstractUser после этого, вы столкнетесь с этой проблемой, как показано в следующем сообщении:

django.db.migrations.exceptions.InconsistentMigrationHistory: миграция admin.0001_initial применяется до его учетной записи зависимости.0001_initial для базы данных "по умолчанию".

наконец, я сбрасываю все базы данных и запускаю

Ответ 13

Я сталкивался с этим при переходе с Wagtail 2.0 на 2.4, но несколько раз видел это, когда стороннее приложение подавляет миграцию после вашей текущей версии, но до версии, на которую вы переходите.

Шокирующе простое решение в этом случае, по крайней мере:

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

т.е. запустить одну миграцию перед попыткой миграции.

Ответ 14

Сначала удалите все файлы миграции и db.sqlite3 и выполните следующие действия:

$ ./manage.py makemigrations myapp 
$ ./manage.py squashmigrations myapp 0001(may be differ)

Удалите старый файл миграции и, наконец,

$ ./manage.py migrate

Ответ 15

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

1. Создайте пользовательскую модель пользователя, идентичную auth.User, назовите ее User (так что многие таблицы имеют одно и то же имя) и установите db_table = 'auth_user' (чтобы она использовала ту же таблицу).
2. Выбросьте все свои миграции
3. Воссоздать свежий набор миграций
4. Пожертвуйте курицу, может быть, две, если вы беспокоитесь; также сделайте резервную копию вашей базы данных
5. Обрезать таблицу django_migrations
6. Подделка - применить новый набор миграций
7. Отключить db_table, внести другие изменения в пользовательскую модель, сгенерировать миграции, применить их

Настоятельно рекомендуется делать это в базе данных, которая обеспечивает ограничения внешнего ключа. Не пытайтесь использовать SQLite на своем ноутбуке и ожидайте, что он будет работать на Postgres на серверах!

Ответ 16

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

У нас есть ряд миграций, которые прекрасно работают в Python 2.7 + Django 1.11. Запуск makemigrations или migrate всегда работает makemigrations и т.д., Даже (для целей тестирования), когда база данных заново создается.

Однако, когда мы переносим проект на Python 3.6 (в настоящее время использующий тот же Django 1.11), я застрял, пытаясь понять, почему одни и те же миграции применяются нормально только при первом запуске. После этого любая попытка запустить makemigrations или даже просто migrate приводит к ошибке:

django.db.migrations.exceptions.InconsistentMigrationHistory

где миграция foo.0040-thing применяется до ее зависимости foo.0038-something-squashed-0039-somethingelse (у нас бывает только одна сквош-миграция... остальные гораздо проще).

Некоторое время меня беспокоило, почему это происходит только на Python 3. Если БД действительно несовместима, это должно происходить постоянно. То, что миграции, кажется, работают отлично, в первый раз, когда они были применены, было одинаково смущающим.

После долгих поисков (включая текущую ветку вопросов и ответов) я наткнулся на вышеупомянутый отчет об ошибке в Django. Наша миграция кабачки действительно использовать b префикс в replaces линии (например, replaces = [(b'', 'foo.0038-defunct'),.......]

После того, как я удалил b префиксы от replaces линии все работало нормально.

Ответ 17

Ваша ошибка по сути:

Migration "B" is applied before its dependency "A" on database 'default'.

Проверка работоспособности: сначала откройте свою базу данных и посмотрите записи в таблице "django_migrations". Записи должны быть перечислены в хронологическом порядке (например: A, B, C, D...).

Убедитесь, что имя миграции "A", указанное в ошибке, совпадает с именем миграции "A", указанной в базе данных. (Они могут отличаться, если вы ранее, вручную, отредактировали или удалили или переименовали файлы миграции)

Чтобы это исправить, переименуйте миграцию A. либо в базе данных, либо переименуйте имя файла. НО убедитесь, что изменения совпадают с тем, что есть у других разработчиков в вашей команде в их базах данных (или совпадают с изменениями в вашей производственной базе данных)

Ответ 18

Эта проблема возникнет в большинстве случаев, если вы продлите модель пользователя после первоначальной миграции. Потому что всякий раз, когда вы расширяете пользователя Abstract, он создает базовые поля, которые присутствовали в модели, такие как email, first_name и т.д.

Даже это применимо к любой абстрактной модели в Django.

Таким образом, очень простое решение для этого - либо создать новую базу данных, затем применить миграцию, либо удалить [В этом случае все данные будут удалены.] Ту же базу данных и повторно применить миграции.