Внесение изменений в модели Django VS. внесение изменений непосредственно в базу данных vs.

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

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

Есть ли какие-нибудь подводные камни, о которых я должен знать, прежде чем делать это изменение непосредственно в базе данных PostGreSQL?

Django ожидает, что БД будет соответствовать файлам models.py, поэтому если вы собираетесь вносить изменения непосредственно в БД, то в будущем у вас могут возникнуть проблемы (у меня точно были...).

В моем случае я вручную удалил ограничение UNIQUE, что вызвало несоответствие между схемой базы данных и models.py, из-за чего Django не позволял мне ни создавать, ни применять миграции, ни обнулять миграции, пока я не выяснил, в чем была проблема, и не изменил DB обратно, чтобы решить ее.

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

Однако лучше попытаться выяснить, почему миграция применяется неправильно, или отменить миграцию и применить ее снова. Этого можно добиться, применив предыдущую-последнюю миграцию.

Чтобы повторно применить миграцию, если миграция, вызывающая проблемы, имеет номер 0003, вы можете сделать следующее:

# we go back to the migration previous to the problematic one
python manage.py migrate myapp 0002

, что приведет к отмене миграции 0003, а затем к повторной миграции:

python manage.py migrate myapp

# then, check if the migration has been applied
python manage.py showmigrations myapp

Вы также можете сбросить и применить все миграции заново.

Другие соображения:

  • Есть ли у учетных данных БД, которые вы используете в Django, достаточно прав для внесения изменений в таблицы БД? Работали ли эти же учетные данные при применении предыдущих миграций?
  • Пробовали ли вы создать объект с проблемным полем как null после миграции, чтобы убедиться, что миграция действительно не работает?
  • Проверяете ли вы правильную БД? (Такое случалось со мной не раз...)

Надеюсь, это поможет вам определить проблему.

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

Вернуться на верх