As per the discussion on https://github.com/spring-projects/spring-boot/issues/15342, Spring's JPA configuration abstraction has a database enum which is meant to indicate a specific database to set up for the persistence provider. Hibernate has an org.hibernate.dialect.Database enum itself but doesn't allow for direct configuration through it: Instead, we can only specify a Dialect implementation (which is typically too specific since we don't mean to suggest a specific database version) or a totally custom DialectResolver implementation.
Ideally, there would be a "hibernate.dialect.database" configuration property, along the lines of "hibernate.dialect" but accepting a Database enum name such as "MYSQL" instead of a specific dialect implementation class. Would it be feasible to include this with Hibernate's default dialect resolvers, shortcutting the current algorithm in StandardDialectResolver with the pre-selected database and only doing runtime detection for the specific dialect version?
After discussing it internally, we concluded that we should expand the use of javax.persistence.database-product-name to the DialectResolver as well. This issue should address this problem.
Therefore, if we set the javax.persistence.database-product-name and there is no hibernate.dialect configuration setting, we can match the Database Enum using the javax.persistence.database-product-name configuration value.
Also, we need to add a comprehensive JavaDoc description to the Database enum where we explain its purpose and the fact that it applies to the auto Dialect resolution mechanism, and Hibernate can accept custom Dialects even if they are not included in the Enum.
It seems that "javax.persistence.database-product-name" is primarily defined for schema generation and not evaluated for regular bootstrapping in Hibernate. It's only really used in HibernateSchemaManagementTool, or am I missing something here?
Other than that, it would indeed be usable for what we're looking for. As far as I can see, EclipseLink evaluates that property too before resolving the database product name from a live Connection. Could Hibernate possibly revisit its standard DialectResolver implementation to evaluate that property for regular bootstrapping as well, shortcutting its runtime resolution to assume a specific database and just evaluate the version for a specific dialect? This seems pretty straightforward given the current StandardDialectResolver implementation, selecting a Database enum entry by name from the property and then calling resolveDialect on it for the version.
If this is indeed feasible and preferable, I'm happy to repurpose this JIRA ticket for it.
We are thinking to expand the use of javax.persistence.database-product-name to the Dialect resolving too.
It seems that you are correct. I had intended it be available for both, but atm it is only used during schema management.
We will correct that. IMO that is the correct solution - I think exposing this enum sets a bad expectation
I will update the description of this issue so we can include a comprehensive JavaDoc description to the Database enum where we explain its purpose and the fact that it applies to the auto Dialect resolution mechanism, and Hibernate can accept custom Dialects even if they are not included in the Enum.
Perfect. Thanks !