matrei commented on code in PR #16458:
URL: https://github.com/apache/grails-core/pull/16458#discussion_r4154869348
##########
grails-data-hibernate5/grails-plugin/src/main/groovy/grails/orm/bootstrap/HibernateDatastoreSpringInitializer.groovy:
##########
@@ -85,21 +85,15 @@ class HibernateDatastoreSpringInitializer extends
AbstractDatastoreInitializer {
@CompileStatic
void configureDataSources(PropertyResolver config) {
- Set<String> dataSourceNames = new HashSet<String>()
+ // The datastore always creates the default connection source, whether
or not it is configured
+ Set<String> dataSourceNames = [ConnectionSource.DEFAULT] as Set<String>
Review Comment:
Good point. `[ConnectionSource.DEFAULT] as Set<String>` gives a
`LinkedHashSet`, which is what the `dataSources` field initialiser and the
`config == null` branch already produced. Only the branch for a non-null
configuration used a `HashSet`. The declared type of `dataSources` stays
`Set<String>`.
With insertion order, the default connection source now always comes first,
followed by the additional data sources in the order the configuration returns
the `dataSources` map. Before, the order was whatever `HashSet` gave. The names
are only iterated to register the `dataSource_<name>`, `sessionFactory_<name>`
and `transactionManager_<name>` beans, so nothing depends on the order.
I've added a feature to `HibernateDatastoreSpringInitializerSpec` in both
modules that checks the contents of `dataSources` with no configuration, with
only `dataSource`, with only `dataSources`, and with both, and that the default
connection source comes first.
##########
grails-doc/src/en/guide/conf/dataSource.adoc:
##########
@@ -83,6 +83,8 @@ dataSource {
}
----
+With GORM for Hibernate, the default data source is always available as the
`dataSource` bean, to inject by name or by type, even when the application has
no `dataSource` block. Without configuration it connects to the in-memory H2
database `jdbc:h2:mem:grailsDB`.
Review Comment:
Yes, only when GORM for Hibernate (`grails-data-hibernate7` or
`grails-data-hibernate5`) is applied. Without it, `DataSourceGrailsPlugin`
still registers a `dataSource` bean only when the application configures one,
so nothing changes there. I've reworded the sentence to make that clearer.
As for disabling it: there was no way to do that before this PR either.
`HibernateDatastore` always creates the default connection source, configured
or not. In the issue's reproduction, an application without a `dataSource`
block has a working `HikariDataSource` for `jdbc:h2:mem:grailsDB` behind
`hibernateDatastore.connectionSources.defaultConnectionSource`, and GORM uses
it. Before, that data source just wasn't registered as a bean. This PR only
registers the data source GORM already creates and uses. It doesn't add one.
Without the H2 driver on the classpath, this default data source can't
connect. That doesn't change with this PR, and the guide now says it needs the
H2 driver. I checked with H2 excluded from the test runtime classpath and no
`dataSource` block, before and after this PR, with the same results:
- without `hibernate.dialect`, startup fails when `hibernateDatastore` is
created ("Unable to determine Dialect without JDBC metadata"), because
Hibernate needs a connection to detect the dialect
- with `hibernate.dialect` set, the application starts, and the first real
query fails with `ClassNotFoundException: org.h2.Driver`
The only difference is that the `dataSource` bean now exists in the second
case. Creating it doesn't open a connection, so it can't make startup fail.
An application that defines its own `dataSource` bean keeps it. The
registrar leaves a `dataSource` name that is already in use alone, and with
this PR that includes singletons. The only way to not have a default data
source is to not apply GORM for Hibernate.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
