With just a simple jdbc configuration of a datasource
spring.datasource.url = jdbc:postgresql://localhost:5433/mydb
spring.datasource.username=postgres
spring.datasource.password=postgres
When starting a Spring Boot 2.0.0 M7 application, we get a confusing log statement
2018-01-21 21:11:49.996 INFO 15380 --- [ main] com.zaxxer.hikari.HikariDataSource : testdb - Starting...
2018-01-21 21:11:50.040 INFO 15380 --- [ main] com.zaxxer.hikari.pool.PoolBase : testdb - Driver does not support get/set network timeout for connections. (Method org.postgresql.jdbc.PgConnection.getNetworkTimeout() is not yet implemented.)
2018-01-21 21:11:50.052 INFO 15380 --- [ main] com.zaxxer.hikari.HikariDataSource : testdb - Start completed.
2018-01-21 21:11:50.056 INFO 15380 --- [ main] o.f.c.internal.database.DatabaseFactory : Database: jdbc:postgresql://localhost:5433/mydb(PostgreSQL 9.5)
It appears it comes from auto-configuration https://github.com/spring-projects/spring-boot/blob/v2.0.0.M7/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/jdbc/DataSourceProperties.java
where the default value for spring.datasource.name is 'testdb'
Looks like Spring Boot is setting the spring.datasource.name as the pool name in HikariConfig somehow.
org.springframework.boot.autoconfigure.jdbc.DataSourceConfiguration
@ConditionalOnClass(HikariDataSource.class)
@ConditionalOnProperty(name = "spring.datasource.type", havingValue = "com.zaxxer.hikari.HikariDataSource", matchIfMissing = true)
static class Hikari extends DataSourceConfiguration {
@Bean
@ConfigurationProperties(prefix = "spring.datasource.hikari")
public HikariDataSource dataSource(DataSourceProperties properties) {
HikariDataSource dataSource = createDataSource(properties,
HikariDataSource.class);
if (properties.getName() != null) {
dataSource.setPoolName(properties.getName());
}
return dataSource;
}
}
See #9547
Sorry, I overlooked completely the fact that name is set by default with such specific name. I think one way to fix this problem would be to make it null by default (with a testdb init for the embedded case).
I've pushed 9107f06 but I am not sure I like it yet. EmbeddedDataSourceConfiguration should reuse what EmbeddedDatabaseConnection does. In particular, DataSourceProperties#determineUrl could be simply reused rather than passing the same value to the builder. I had a quick look to that (overriding the DataSourceFactory to use) and it looks doable.
I could use a second look on the initial proposal.
@snicoll I've pushed the naming logic into DataSourceProperties and exposed it by making deduceDatabaseName() public. The EmbeddedDatabaseConnection now requires a databaseName parameter.
That feels fairly sensible. I think the default name is a concern of auto-configuration, so it's best to keep it in that module. As a bonus we also can remove the generate unique name stuff in EmbeddedDataSourceConfiguration because deduceDatabaseName already does that.
Feel free to re-open the issue if the change doesn't feel right.
Most helpful comment
@snicoll I've pushed the naming logic into
DataSourcePropertiesand exposed it by makingdeduceDatabaseName()public. TheEmbeddedDatabaseConnectionnow requires adatabaseNameparameter.That feels fairly sensible. I think the default name is a concern of auto-configuration, so it's best to keep it in that module. As a bonus we also can remove the generate unique name stuff in
EmbeddedDataSourceConfigurationbecausededuceDatabaseNamealready does that.Feel free to re-open the issue if the change doesn't feel right.