Процесс миграции Django для Elasticbeanstalk / нескольких баз данных

Я разрабатываю небольшое веб-приложение, используя Django и Elasticbeanstalk. Я создал приложение EB с двумя средами (промежуточной и рабочей), создал экземпляр RDS и назначил его своим средам EB.

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

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

Поэтому, как только я развертываю текущую версию приложения в определенной среде, «manage.py migrate» в большинстве случаев терпит неудачу, потому что таблицы уже существуют или не существуют, даже если они должны (потому что другая среда уже создала таблицы).

Поэтому мне было интересно, как справиться с процессом миграции при использовании нескольких сред для разработки, подготовки и производства с некоторыми общими и некоторыми эксклюзивными экземплярами базы данных, которые могут не всегда отражать одну и ту же структуру?

Должен ли я исключать файлы миграции из репозитория кода и развертывания eb и запускать makemigrations & migrate после каждого развертывания? Не следует ли запускать миграции автоматически с помощью .ebextensions и применять все миграции вручную через один из экземпляров?

Каков рекомендуемый способ использования одного и того же приложения Django с разными экземплярами базы данных в разных средах?


person wuser92    schedule 14.09.2016    source источник


Ответы (1)


Кажется, вы могли удалить таблицу или миграции в какой-то момент времени.

Когда вы запускаете makemigrations, django создает migratins, а когда вы запускаете migrate, он создает базу данных в зависимости от того, что указано в файле настроек.

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

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

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

person sprksh    schedule 14.09.2016
comment
Но это именно то, что я имею в виду. В целях разработки и тестирования я могу удалить таблицу (или сделать что-то еще) в какой-то момент. И мне также пришлось бы применять те же транзакции к другим БД, чтобы избежать ошибок, если я разверну папку миграции в среде Elastic Beanstalk. Не вредно ли игнорировать файлы миграции и позволить каждой системе сохранять свои собственные миграции? - person wuser92; 16.09.2016
comment
Вы можете удалить таблицу, но не выполнять операцию непосредственно в базе данных. Сделайте это через django ORM. Допустим, вы хотите удалить таблицу, вы должны удалить эту модель и выполнить миграцию. Тогда, когда вы переносите его индивидуально на каждый сервер, вы никогда не столкнетесь с какими-либо проблемами. - person sprksh; 17.09.2016
comment
Я не использовал эластичный бобовый стебель. Но да, это обычное дело. вы игнорируете файлы миграции и имеете отдельные миграции на каждом сервере (разработка, производство, тестирование). Обычно, если вы используете git, вы помещаете migrations/ в .gitignore. поэтому файлы миграции создаются на каждом сервере отдельно. - person sprksh; 17.09.2016