1

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

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

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

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

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

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

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

ответ

1

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

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

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

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

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

+0

Но это именно то, что я имею в виду. Для разработки и тестирования я могу в какой-то момент удалить таблицу (или сделать что-то еще). И мне пришлось бы также применять те же транзакции к другим БД, чтобы избежать ошибок, если я разворачиваю папку миграций в среду Elastic Beanstalk. Хотелось ли игнорировать файлы миграции и позволять каждой системе сохранять свои собственные миграции? – wuser92

+0

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

+0

Я не использовал эластичный бобовый шток. Но да, это нормальная вещь. вы игнорируете файлы миграции и имеете отдельные миграции на каждом сервере (dev, production, testing). Обычно, если вы используете git, вы переносите миграции/в .gitignore. и поэтому файлы миграции создаются на каждом сервере отдельно. – sprksh

Смежные вопросы