Как обычно поступают с миграциями Django, если схема БД шире и используется другими приложениями?
Лучше на примере:
Есть проект, состоящий из двух частей:
1 - Приложение на джанге.
2 - Приложение (не обязательно на питоне), которое постоянно мониторит внешние ресурсы и заполняет БД.
Т.е. оба приложения работают с одной БД. Причем второе имеет в схеме таблицы исключительно для своих целей, о которых джанге знать не надо.
Из-за этого как-то странно определять всю схему базы средствами Django ORM, и структура всего проекта видится мне примерно так:
|
`- django_proj (тут приложение на джанге)
`- monitoring_app (тут приложение, постоянно заполняющее БД. написано на Java, Go или питоне)
`- db (а вот тут собственно определена схема БД и файлы миграции как структуры, так и данных)
Таким образом я держу схему БД в одном месте, которое справедливо не включено в какое-то из приложений, так как относится к обоим. Но как быть с моделями джанги? Я конечно сделаю их все managed=False, но все равно останутся модели от django.contrib.* приложений (admin, auth,..), которые потребуют джанговские миграции. И в итоге у меня получатся две системы миграций, которые еще и как-то синхронизировать может придется.
Как вы поступаете в таких ситуациях? Как это обычно делают?
@rSedoy
Поток данных
[сторонний внешний ресурс] -> [часть 2 собирает данные по api и, обработав, пихает их в БД] <-> [БД] -> [часть 1 т.е. джанга отображает данные юзеру]
При этом [часть 2] иногда читает данные из БД для обработки вновь поступающих данных
Даже если придется переписать то приложение с другого ЯП
- это не выглядит универсальным решением. Как поступают те, кто переписывать отлаженный код не намерен?
Как-то странно пихать это приложение в папку с джангой, описывать там модели, которые не будут использоваться.
sim3x спасибо, что помогаете.
Я совсем еще новичок в джанге, но слышал как опытные разработчики отказываются от миграций средствами джанги и пишут DDL-скрипты сами.
Также интересна ситуация, когда уже есть огромная работающая система и джанга приходит туда позже для реализации какого-нибудь дашборда. Как же тут поступают матерые веб-разработчики?
А по джанго коммандс - я как понял это возможность расширять арсенал manage.py своими командами.
wawa, А теперь давайте подумаем почему такие люди не являются профессионалами
Они нарушают дзен питона - kiss
Они тестируют в три раза больше без улучшения покрытия по факту
Они нарушают консистентность
Про ситуацию, когда джанга приходи для минорного использования
- непонятно зачем она туда приходит, если в таких проектах уже есть орм или люди, которые умеют сделать ее аналог для реализации рест и последующего внедрения туда ангуляра или реакта для дашборда
А по джанго коммандс - я как понял это возможность расширять арсенал manage.py своими командами.
А как насчет особенностей СУБД? Разработчики ОРМ не могли же предусмотреть все особенности того же постгрес. И в итоге makemigrations генерит не самый подходящий скрипт миграции. А все эти механизмы постгреса как check,triggers,functuons,view - за бортом?
Спасибо. Я просто зарылся в доки постгреса (столько там всего) и пытаюсь понять как уживаются эти два мира. С одной стороны богатейший функционал PG, что называется ближе к данным, а с другой - Django ORM, делающий всё чтобы я забыл про особенности, читай возможности, PG.
