#django #heroku-postgres
#django #heroku-postgres
Вопрос:
У меня есть веб-приложение Django, запущенное на Heroku с Heroku Postgres. Несколько дней назад я внес несколько изменений в модели приложения, добавив, а затем удалив unique=True некоторые поля модели (среди прочего, просто немного повозившись) и выполнив некоторые миграции. Это, безусловно, что-то сломало, и, к сожалению, я обнаружил это только несколько дней спустя, после того, как я произвел множество дополнительных миграций в моей локальной базе данных. Единственный способ, которым я смог это исправить, был с помощью:
python manage.py migrate --fake
Это сработало нормально в моем локальном / dev postgres, но в рабочей среде это все еще не работает, когда я пытаюсь выполнить миграции и перенести. При запуске migrate:
django.db.utils.ProgrammingError: table "publicinteraction_smoothmessage_extra_software" does not
exist
Поскольку прошло несколько дней, я не знаю точно, какую миграцию я подделал или нет, и раздел в Django docs о «риске ручного исправления —fake» также был замечен слишком поздно…
Поможет ли это запустить python manage.py migrate publicinteraction zero или это приведет к потере моих данных?
Это мой первый проект в производстве с реальными пользователями, и для разработчика-самоучки, владеющего Python и Django, сталкиваться с такими проблемами в новинку. Копаться в производственной базе данных немного неудобно и слишком нервирует для моего уровня квалификации на данный момент.
Как мне поступить, не потеряв все свои данные? Также очень ценятся рекомендации, которые следует учитывать на будущее, когда дело доходит до выполнения миграции локально или на производстве 🙂
Комментарии:
1. не подделывайте миграции, если вы не знаете, что делаете, вам следует просмотреть свои миграции и посмотреть, какие изменения вы не применяли в рабочей базе данных, и применить их, zero удалит все ваши таблицы и эти данные в этом конкретном модуле.
2. также вы можете отменить только миграцию, из которой вы подделали, или даже немного безопаснее удалить их строки из таблицы миграции docs.djangoproject.com/en/3.1/topics/migrations / …
3. ОК. Но есть ли простой способ выяснить, какая миграция была подделана? Я надеялся, что Django мог бы добавить комментарий или что-то подобное в 00xx_migration.py, сообщающий мне, что это было подделано, но я, похоже, не могу найти ни одного, так что, думаю, нет 🙂
4. вы можете проверить отметку времени, когда применяется миграция, в таблице django_migrations и сопоставить время с инцидентом
5. Да, я в курсе этого, но, как я упоминал в своем посте, я не знаю точно, когда произошла поддельная миграция, поэтому я все еще немного потерян здесь.