@wawa

Как обычно поступают с миграциями Django, если схема БД шире и используется другими приложениями?

Лучше на примере:
Есть проект, состоящий из двух частей:
1 - Приложение на джанге.
2 - Приложение (не обязательно на питоне), которое постоянно мониторит внешние ресурсы и заполняет БД.
Т.е. оба приложения работают с одной БД. Причем второе имеет в схеме таблицы исключительно для своих целей, о которых джанге знать не надо.
Из-за этого как-то странно определять всю схему базы средствами Django ORM, и структура всего проекта видится мне примерно так:
|
`- django_proj (тут приложение на джанге)
`- monitoring_app (тут приложение, постоянно заполняющее БД. написано на Java, Go или питоне)
`- db (а вот тут собственно определена схема БД и файлы миграции как структуры, так и данных)

Таким образом я держу схему БД в одном месте, которое справедливо не включено в какое-то из приложений, так как относится к обоим. Но как быть с моделями джанги? Я конечно сделаю их все managed=False, но все равно останутся модели от django.contrib.* приложений (admin, auth,..), которые потребуют джанговские миграции. И в итоге у меня получатся две системы миграций, которые еще и как-то синхронизировать может придется.
Как вы поступаете в таких ситуациях? Как это обычно делают?
  • Вопрос задан
  • 150 просмотров
Решения вопроса 1
sim3x
@sim3x
Джанга знает обо всем
Приложение написано на питоне и работает через орм джанги и джанго коммандс

Уменьшает количество проблем на пару порядков
Даже если придется переписать то приложение с другого ЯП
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы
14 авг. 2018, в 10:57
2400 руб./за проект
14 авг. 2018, в 10:44
3000 руб./за проект
14 авг. 2018, в 09:38
5000 руб./за проект