Size: a a a

Java/Kotlin and more

2021 January 15

AE

Alexandr Emelyanov in Java/Kotlin and more
Алексей Васин
всем привет, кто нибудь мб знает, можно ли сделать два датасурса, при этом один будет дефолтно через автоконфигурацию создавать пропертями из ямла, а второй как бин тупо обьявляться в конфиг классе
Можно
источник

АВ

Алексей Васин... in Java/Kotlin and more
а можно где нибудь пример чекнуть? у меня сейчас почему-то автоконфигурация датасурса дизейблится
источник

AE

Alexandr Emelyanov in Java/Kotlin and more
Алексей Васин
а можно где нибудь пример чекнуть? у меня сейчас почему-то автоконфигурация датасурса дизейблится
Вроде не сложно находилось в Гугле
источник

АВ

Алексей Васин... in Java/Kotlin and more
там везде примеры, где тупо два бина обьявляется со своими настройками
источник

АВ

Алексей Васин... in Java/Kotlin and more
без связки одна через автоконфигурацию, а вторая через бин)
источник

V

Vlad in Java/Kotlin and more
Алексей Васин
без связки одна через автоконфигурацию, а вторая через бин)
такой конфигурации нету, спринг магию не делает, спринг берет твои данные из applicatin.properties и делает бин datasource. вот и все. если ты сам сделаешь бин datasurce, тебе не надо будет его нигде указывать, и не  надо будет в проперти файле писать настройки, спринг потдянет в контекст созданный тобой датасоур по имени класса, не важно как ты даже бин назовешь. Твой выход, это сделать 2 бина датасоурса, и над главным поставить аннотацию @Primary, я писал уже выше
источник

АВ

Алексей Васин... in Java/Kotlin and more
почему он не может брать настройки из ямл и считать что этот датасурс праймари, а если появится еще один бин датасурса, нейминг там будет другой и он его в итоге тоже добавит в контекст?
источник

V

Vlad in Java/Kotlin and more
потому что из ямл файла сделается обычный бин datasource, сделаешь их 2  - получишь скорее всего экспешн, что спринг не разобрался, какой брать, но это надо проверить
источник

V

Vlad in Java/Kotlin and more
а в чем проблема сделать обычный бин? не через ямл файл
источник

VS

Vitaly Sirotkin in Java/Kotlin and more
Алексей Васин
почему он не может брать настройки из ямл и считать что этот датасурс праймари, а если появится еще один бин датасурса, нейминг там будет другой и он его в итоге тоже добавит в контекст?
потому что там @ConditionalOnMissingBean
источник

АВ

Алексей Васин... in Java/Kotlin and more
а это можно как-то заоверайдить?
источник

VS

Vitaly Sirotkin in Java/Kotlin and more
нет
источник

VS

Vitaly Sirotkin in Java/Kotlin and more
но ты можешь сделать свой DatasourceHolder какой нибудь, в котором будет спринговый ДС и твой созданный руками
источник

RS

Ruslan Stelmachenko in Java/Kotlin and more
Алексей Васин
там везде примеры, где тупо два бина обьявляется со своими настройками
да, это пичалька в буте. пока 1 датасоурс - все хорошо. как только надо 2 - надо и первый делать руками. а это ж не просто пару пропертей в ямле. это и миграции и куча всего другого перестает из коробки работать.

возможно, если первый сделать @Primary, то это поможет и остальные автоконфигурации заработают (миграции, жпа и прочее). но это тоже костыль. а если нужно миграции на оба датасорса? и вот уже нужно и миграции настраивать вручную для обоих.

это все сильно повышает сложность на ровном месте. я даже заметил, что бывает это влияет на архитектурные решения. когда, например, вроде бы и хорошо бы 2 БД подключить архитектурно, но когда вспоминаешь, сколько это вызовет доп. работы по написанию и поддержке всего, что раньше ты бы получил из коробки, то невольно задумываешься "а может ну его нафиг эти 2 БД, может все же одной тут можно обойтись..."
источник

VS

Vitaly Sirotkin in Java/Kotlin and more
ну миграции из приклада накатывать конечно такое себе. но в целом да, это боль каждый раз
источник

D

DOCDOCTOR in Java/Kotlin and more
Vitaly Sirotkin
ну миграции из приклада накатывать конечно такое себе. но в целом да, это боль каждый раз
А от куда лучше? Отдельную репу с скриптами? Чем это лучше?
источник

VS

Vitaly Sirotkin in Java/Kotlin and more
ну например инит-контейнером если в терминах кубера
источник

VS

Vitaly Sirotkin in Java/Kotlin and more
лучше тем, что более контролируемо, и не привязано к версии приклада
источник

D

DOCDOCTOR in Java/Kotlin and more
Vitaly Sirotkin
лучше тем, что более контролируемо, и не привязано к версии приклада
Понял, почитаю еще
источник

RS

Ruslan Stelmachenko in Java/Kotlin and more
Vitaly Sirotkin
ну миграции из приклада накатывать конечно такое себе. но в целом да, это боль каждый раз
согласен про миграции. но зачастую так и делают. тем более что бут этому способствует. ведь там это встроено)
источник