Проблема миграции совместной работы Django

В настоящее время у меня возникла проблема при работе с моими друзьями над одним и тем же проектом Django. Ситуация заключается в том, что каждый раз, когда кто-то из нас вносит изменения в базу данных и если другие люди не мигрировали вовремя, они получают ProgrammingError: Column not exist ошибка. Это уже произошло несколько раз, и мы до сих пор не можем найти способ избежать этого. Вопрос:

  1. Какой лучший способ решить эту проблему, если она возникла?
  2. Какой лучший процесс для аннулирования этой проблемы?

Спасибо всем!

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

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

python manage.py dumpdata <app-name>

он экспортирует JSON-файл, который впоследствии можно будет загрузить в базу данных

python manage.py loaddata <app-name>

NOTE: по какой-то причине, если вы загружаете данные и получаете ошибку кодировки, обязательно откройте файл, сохраните его в блокноте и измените кодировку на utf-8

  1. Если вы работаете с локальной базой данных, то просто мигрируйте. Это повседневная работа в django. По крайней мере, по моему опыту.

    Для баз данных, которые находятся в общем доступе, это совсем другое дело. Я бы, вероятно, (а) если нет devops, мигрировал базу данных непосредственно после изменения схемы. Убедитесь, что определенная ветвь (т.е. разработка) всегда синхронизирована с сервером базы данных. Или (b) при наличии devops разрешить ветке объединяться только в том случае, если выполняется условие: миграция, связанная с изменениями модели в вашем коммите, будет успешной. И тогда пусть devops обрабатывает миграцию автоматически, чтобы поддерживать базу данных в синхронизации.

    .

    .

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

    .

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

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