Infer database capabilities without opening a JDBC connection on runtime init

[yrodiere]

Description

cc @Sanne , as discussed. Creating to keep track of this potential enhancement.

#13435 made sure that we correctly infer database capabilities when the application boots, by opening a connection to the database and requesting database metadata from the JDBC driver.

This connection is problematic if the database is not available when the application boots. In that case, the connection will fail, the exception will be logged and Hibernate ORM will assume that none of the "extra" capabilities are available. Which may lead to runtime errors, such as #12412.

Ideally, we should provide hardcoded capabilities for well-known databases and drivers, so that the JDBC connection is not always needed.

Implementation ideas

We could pass the required metadata along with the driver/dialect metadata, during static init. At runtime, if we have such metadata (i.e. we're dealing with a well-known database), we override the JdbcEnvironementInitiator to take the metadata into account; otherwise, we fall back to the default initiator which will open a JDBC connection.

[ghost]

/cc @Sanne, @gsmet

[yrodiere]

CC @gsmet: this issue is related to the discussion we had regarding the introduction of a property to set the database version.

I think this will have to be a build-time property, unfortunately...

[Sanne]

Right, great to see we had an issue already. So "capabilities" are better represented in ORM 6 with the version; having that exposed would be really nice and a more user friendly way to expose this.

[yrodiere]

Note the database capabilities we're talking about go way beyond just the vendor and DB version.

For example, OracleDialect does this on startup:

https://github.com/hibernate/hibernate-orm/blob/2fb7cdd08bc220b726de6fbe882787bbf04441a5/hibernate-core/src/main/java/org/hibernate/dialect/OracleDialect.java#L188-L192

Allowing it to determine the max length of the VARCHAR SQL type:

https://github.com/hibernate/hibernate-orm/blob/2fb7cdd08bc220b726de6fbe882787bbf04441a5/hibernate-core/src/main/java/org/hibernate/dialect/OracleDialect.java#L319-L323

I'm sure there are plenty of such tricks in Hibernate ORM, so addressing them smartly at build time will require a good deal of thinking.

[yrodiere]

Another potential issue somewhat related to this feature is that Hibernate ORM stores the "JDBC metadata" globally, which can be a problem in a multi-tenant scenario with multiple databases. From what I can see the metadata is retrieved from the database corresponding to the default tenant and then used globally for all tenants:

https://github.com/hibernate/hibernate-orm/blob/176978cc429775019e8561e573f67044bdcdbe45/hibernate-core/src/main/java/org/hibernate/engine/jdbc/env/internal/JdbcEnvironmentInitiator.java#L229-L238

https://github.com/hibernate/hibernate-orm/blob/176978cc429775019e8561e573f67044bdcdbe45/hibernate-core/src/main/java/org/hibernate/engine/jdbc/env/internal/JdbcEnvironmentInitiator.java#L412-L415

I can see this being a problem if different tenants have different database version/configuration with different metadata.

Solving this (separate) issue would probably require substantial changes in Hibernate ORM. Basically we'd need some dialect-related metadata to be tenant-scoped (ConnectionProvider-scoped?).

Anyway, I'm going on a tangent here, but it's good to keep this in mind.

[yrodiere]

FWIW we'll need to address at least this upstream issue before we can work on this, and maybe more: https://hibernate.atlassian.net/browse/HHH-17425

[yrodiere]

All relevant problems seem to have been solved upstream:

• https://hibernate.atlassian.net/browse/HHH-17269
• https://hibernate.atlassian.net/browse/HHH-17425

We should be able to integrate the feature in Quarkus, which will involve:

• adding a Quarkus configuration property to start Hibernate ORM offline (see https://hibernate.atlassian.net/browse/HHH-17269)
• adding checks to all "on startup" features (e.g. schema generation) to disable them by default when starting offline, and throw an exception if they are explicitly requested
• adding Quarkus configuration properties to configure dialects (see https://hibernate.atlassian.net/browse/HHH-17425)

[yrodiere]

BTW https://hibernate.atlassian.net/browse/HHH-18601 could help make this "offline startup" feature safer, but is not an absulte requirement: this can come as an improvement later.