Fix datasource prefix in multiple-datasource configuration doc

[membersound]

https://docs.spring.io/spring-boot/docs/current/reference/html/howto-data-access.html

The example states the following:

@Bean
@Primary
@ConfigurationProperties("app.datasource.first")
public DataSourceProperties firstDataSourceProperties() {
	return new DataSourceProperties();
}

@Bean
@Primary
@ConfigurationProperties("app.datasource.first") //TODO this is wrong.
public DataSource firstDataSource() {
	return firstDataSourceProperties().initializeDataSourceBuilder().build();
}

Problem: the key for the DataSource must be:
app.datasource.first.<datapool name>, eg app.datasource.first.hikari. Only then the properties like app.datasource.first.hikari.minimum-idle will be taken into account.

Likewise for the second ds in the example.

[philwebb]

I agree, this would be more consistent with the way that we bind datasource properties ourselves. It's also possible to drop the hikari prefix in the property itself (app.datasource.first.minimum-idle) but I like your approach better.

[snicoll]

I disagree it is wrong for the record. If you are building your own DataSource chances are that you know if you want to expose additional properties or not (probably) and the pool implementation that you've chosen.

What is really wrong in the example is that we return DataSource and therefore we have no way to teach the annotation processor which keys it has to collect. If you want to get a full namespace with the three connection pools we support it's a lot more work.

The reporter mentioned hikari which tend to confirm my first point. If you know the connection pool you want to use, then I don't see a reason for having a sub-namespace named "Hikari". Perhaps we want to separate things nicely though ("properties" as we do in other parts).

[philwebb]

Binding the same key to DataSourceProperties and DataSource is a bit of smell. I think we changed our internal code because of that.

[snicoll]

I think we changed our internal code because of that.

We did because we had three connection pools to support. It's not so obvious in a custom scenario IMO but I agree that it would be better to have a dedicated namespace for it just for the sake of the best practice.

[membersound]

Well the thing is: if you take the following standard properties for a single database:

spring.datasource.url
spring.datasource.username
spring.datasource.password
spring.datasource.hikari.minimum-idle

The question is: how would you arrange them for multiple databases.
For me this is quite clear: you want to express as much separation as possible through the keys. So you add your custom "namespace" for example right after spring.datasource. Which then turns:

spring.datasource.primary.url
spring.datasource.primary.username
spring.datasource.primary.password
spring.datasource.primary.hikari.minimum-idle

spring.datasource.secondary.url
spring.datasource.secondary.username
spring.datasource.secondary.password
spring.datasource.secondary.hikari.minimum-idle

It's not very intuitive having to remove the *.hikari namespace in order to get the fields picked up.

[snicoll]

It's not very intuitive having to remove the *.hikari namespace in order to get the fields picked up.

If we decide to document something else than hikari that's not going to help you. That section is an example of custom code: If you want an hikari sub-namespace, it may not work for someone else. If you want one, you're free to do so in your own code of course.

Having said that, we've identified two issues here so we'll update the doc.

[membersound]

One sidequestion: what if there is a global hikari connection pool definition, overriding defaults:

spring.datasource.hikari.minimum-idle=
spring.datasource.hikari.maximum-pool-size=
spring.datasource.hikari.idle-timeout=
spring.datasource.hikari.data-source-properties.cachePrepStmts=true
...

Would it be possible to "inject" those "global" defaults into the multi-datasource properties? It would be handy to provide global database configurations that should apply to any of the custom databases, eg regarding the advised hikari defaults for mysql: https://github.com/brettwooldridge/HikariCP/wiki/MySQL-Configuration

If they could be inherited or just injected/joined, one would not have to redefine them for each of the multi-databases. Or is the only chance redefining them, like:

spring.datasource.primary.hikari.minimum-idle="${spring.datasource.hikari.minimum-idle}
spring.datasource.secondary.hikari.minimum-idle="${spring.datasource.hikari.minimum-idle}