Можно

а можно где нибудь пример чекнуть? у меня сейчас почему-то автоконфигурация датасурса дизейблится

Вроде не сложно находилось в Гугле

там везде примеры, где тупо два бина обьявляется со своими настройками

без связки одна через автоконфигурацию, а вторая через бин)

такой конфигурации нету, спринг магию не делает, спринг берет твои данные из applicatin.properties и делает бин datasource. вот и все. если ты сам сделаешь бин datasurce, тебе не надо будет его нигде указывать, и не  надо будет в проперти файле писать настройки, спринг потдянет в контекст созданный тобой датасоур по имени класса, не важно как ты даже бин назовешь. Твой выход, это сделать 2 бина датасоурса, и над главным поставить аннотацию @Primary, я писал уже выше

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

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

а в чем проблема сделать обычный бин? не через ямл файл

потому что там @ConditionalOnMissingBean

а это можно как-то заоверайдить?

нет

но ты можешь сделать свой DatasourceHolder какой нибудь, в котором будет спринговый ДС и твой созданный руками

да, это пичалька в буте. пока 1 датасоурс - все хорошо. как только надо 2 - надо и первый делать руками. а это ж не просто пару пропертей в ямле. это и миграции и куча всего другого перестает из коробки работать.

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

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

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

А от куда лучше? Отдельную репу с скриптами? Чем это лучше?

ну например инит-контейнером если в терминах кубера

лучше тем, что более контролируемо, и не привязано к версии приклада

Понял, почитаю еще

согласен про миграции. но зачастую так и делают. тем более что бут этому способствует. ведь там это встроено)