Е
Амбрелла потому что :)))
Size: a a a
2021 April 14
ГК
AD
не аргумент)
ГК
У меня в амбрелла не то что БД как неймспейс разные, даже БД как сервис разные)))
Е
А зачем аргумент? Лучше скажите как надо :)
Е
У каждого приложения свои конфиги экты, свои процессы экты и так далее?
ГК
типа того
AD
во-первых если амбрелла и одно из приложений это интерфейс к БД - от используйте везде этот интерфейс. Если нет приложения-интерфейса и в каждом приложении разный интерфейс - то разные сделайте БД
Е
Сейчас как "во-первых"
Е
Я хотел сделать некий единый для всех приложений интерфейс доступа к БД.
AD
тогда в чем проблема, приложение-интерфейс как было так и остается, миграции должны быть в нем
AD
схемы уже по желанию, либо тоже в нем, либо в соответствующих приложениях
Е
Фиг с ними с миграциями. Речь о схемах.
AD
если общих таблиц нет то смысла дублировать схемы тоже нет
Е
сейчас и схемы и миграции в этом приложении БД
VS
если у вас вообще полная динамика, то тут вариант с редиректом может быть только такой, наверное,
через
- порт
-
- по каким-то эвристикам найти нужный, забрать его адрес
- зная порт иадрес, соорудить
- редирект
через
rpc запросить:- порт
cowboy-
:inet.getifaddrs(), все интерфейсы машины- по каким-то эвристикам найти нужный, забрать его адрес
- зная порт иадрес, соорудить
url- редирект
AD
значит так и оставляйте
Е
Уточню. Допустим есть некий тип
Для этого я хочу создать соответствующий
Но для этого приложение БД (схема-то в нем) должно знать о
MyType, его напрямую в БД не сохранишь, нужно конвертить во что-нибудь поддерживаемое постгресом.Для этого я хочу создать соответствующий
Ecto.Type и в нем делать конвертации. Этот Ecto.Type подключить к схеме.Но для этого приложение БД (схема-то в нем) должно знать о
MyType, вот этого и хотелось бы избежать.Е
Кошерно ли тогда вынести эту схему в приложение с
MyType?Е
Тем более, что остальные приложения никогда к этой схеме не обращаются.