Fixes gh-22824
Comment From: onobc
@wilkinsona not sure if this is what you had in mind - let me know where we need to adjust. I have a couple of points/questions/caveats to discuss as well.
Relies on metadataprovider
~~As it is written, it relies on the available metadata providers to generate the validation query. Will it ever be the case that one of the routed datasources is not of the types we know about? Is that even possible?~~
I have since figured out this is not an issue as described here
By default, Spring Boot provides metadata for all supported data sources; you can add additional DataSourcePoolMetadataProvider beans if your favorite data source isn’t supported out of the box. See DataSourcePoolMetadataProvidersConfiguration for examples.
Duplicate indicators
If a routed datasource is also a registered @Bean DataSource then it will have a regular DataSourceIndicator created as well as be represented in the RoutingDataSourceHealthIndicator. The IsolationLevelDataSourceRouter seems like an example where the routed datasources are most likely already registered DataSource beans.
* Option 1 - do nothing
* Option 2 - add boolean property to "deduplicate" (ignore the routing datasource when its already represented)
One edge case on option 2 is when one of the routed datasources is already covered but another is not. Would we ignore only the covered target datasource in the routing health indicator? That would be strange.
I am inclined to go w/ option 1. I am curious to hear others thoughts as well.
Comment From: wilkinsona
This looks great. Thank you, @bono007.
I am inclined to go w/ option 1. I am curious to hear others thoughts as well.
Agreed. I think this is the better option.
Having the RoutingDataSourceHealthIndicator is helpful for testing as well as for future extensions to the indicator when/if needed
Agreed again. When looking at the main code I was tempted to get rid of it, but having looked at the tests I think it's useful to have the distinction. It's also a package-private implementation detail so we can refine in the future as needed without worrying about backwards compatibility.