Немного предыстории: Мы используем контейнер docker для запуска нашего проекта django, и, поскольку над проектом работает несколько человек, мы поместили папку migrations в gitignore (правильно это или нет - отдельный вопрос), чтобы избежать конфликтов слияния.
Каждый раз makemigrations запускаются - всегда 001_initial.py, поскольку Docker копирует проект git, у которого нет migrations в этом. Команда migrate определяет, какие изменения применить к базе данных. Сейчас это становится обычной проблемой, когда иногда, когда появляется новое поле (или поле переименовано) - хотя эти изменения находятся в myapp\migrations\001_initial.py - после выполнения команды migrate django думает, что эти изменения уже в базе данных и он не применяет никаких миграций. Мы стираем базу данных и повторно выполняем миграции, что отлично подходит для разработки, но, очевидно, не работает для производства. Есть вопросы, связанные с этим, и людям рекомендуется вернуться к предыдущим миграциям, которые, кажется, сбрасываются и в некоторых случаях работают для нас - например:
python manage.py migrate myapp zero
Но это не работает всегда, если есть отношения в базе данных с полностью новыми таблицами (поэтому django жалуется, что таблица не существует) при попытке вернуться, и отчасти потому, что наши миграции в контейнере docker всегда начинаются с 001_initial.py.
Это * Ошибка 1030 * или мы не следуем какой-либо хорошей практике, отсюда и проблема? Мы думаем об удалении папки migrations из gitignore, что позволяет вернуться к более старым миграциям, однако мы не совсем уверены, решит ли это проблему, и, кроме того, проект django запускается в контейнере, поэтому migrations файлов внутри контейнер не привязан к git репо.