Only apply autoconfiguration that injects DataSource by type, if there is a single or primary DataSource #12914
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, an error is thrown if I add multiple
DataSource
s to my context.There are two workarounds for this issue:
DataSource
s as@Primary
DataSource
by typeIt is easy to do 1. but this can be arbitrary decision unless the user knows exactly what auto-configuration is being applied. It can lead to subtle differences in behaviour which can trip you up, especially if you don't understand what you are doing by choosing this option.
It is hard to do 2. without a full knowledge of which auto-configurations. A piece of auto-configuration knows if it wants to inject by type and can foresee that injecting a
DataSource
by type is likely to trip people up. Therefore, they should make use ofConditionalOnSingleCandidate
so they don't trip anybody up. Afterall, if somebody has already added multiple DataSources without into their application, then they probably know what they want to do with them.This was proposed in #5541 but the commit that closed that ticket did not actually add this annotation to either
DataSourceAutoConfiguration
norDataSourceTransactionManagerAutoConfiguration
so this PR fixes that and also updates the documentation to reflect this behaviour.