HHH-13184 - Oracle dialect detection does not return latest dialect in the default case

[joelarnold]

No description provided.

[Sanne]

oh, wow interesting mistake. Thanks!

[Sanne]

@gbadner this applies to 5.3 only, yet I believe it should be merged. Your call

[vladmihalcea]

@gbadner I also think this should be backported to 5.3 as it prevents applications from starting if the hibernate.dialect property was not explicitly configured.

[gbadner]

@joelarnold, thanks for the PR! It will applied to the next Hibernate ORM 5.3 release.

[dazey3]

@vladmihalcea @joelarnold @gbadner Is there any intention of backporting this fix to 5.2? I have a JPA 2.1 application that is using 5.2.18, but is having this problem now after updating to Oracle 18c.

HHH000342: Could not obtain connection to query metadata : Unable to determine Dialect to use [name=Oracle, majorVersion=18]; user must register resolver or explicitly set 'hibernate.dialect'

It is not feasible for my application to have to set the hibernate.dialect property

[Sanne]

@dazey3 5.2 is no longer maintained - the oldest version actively maintained is branch 5.3, but I would encourage you to upgrade to 5.5+ . (All maintained versions have the fix)

[dazey3]

@Sanne That's disappointing. Using 5.3+ fails to work as the JPA 2.2 binaries are not available; only the 2.1 binaries are available:

Stack Dump = java.lang.NoClassDefFoundError: javax.persistence.TableGenerators
at org.hibernate.cfg.AnnotationBinder.bindDefaults(AnnotationBinder.java:227)
at org.hibernate.boot.model.source.internal.annotations.AnnotationMetadataSourceProcessorImpl.prepare(AnnotationMetadataSourceProcessorImpl.java:189)
at org.hibernate.boot.model.process.spi.MetadataBuildingProcess$1.prepare(MetadataBuildingProcess.java:165)
at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:262)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:1215)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:1246)
at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:141)

I am testing Hibernate integration with Open Liberty; specifically JPA 2.1 integration. This is not an application that can simply add the appropriate javax packages to the application classloader or specify the hibernate dialect as a persistence property. This bug essentially makes any Hibernate integration with JPA 2.1 void since Oracle is not supported by default, there is no Hibernate version that supports JPA 2.1 and has this fix, and the application needs to be DB platform agnostic. A shame really.

[beikov]

So why can't you use the JPA 2.2 integration of Open Liberty @dazey3?

[Sanne]

Right, JPA 2.2 is strictly backwards compatible so it should be easy to upgrade.

[dazey3]

@beikov
Correct, I could use the jpaContainer-2.2 integration for Open Liberty, which would supply the javax.persistence 2.2 version packages to satisfy Hibernate 5.3+. It would be very easy to make such a change and certainly our jpaContainer-2.2 testing does already use Hibernate 5.3+ without this issue.

However, having to use the JPA 2.2 packages because I am forced to upgrade to Hibernate 5.3+ would negate the purpose of testing Open Liberty's jpaContainer-2.1 feature, which supplies the javax.persistence 2.1 version packages, with Hibernate + Oracle. My point is that there is no Hibernate version, built with JPA 2.1 support, that also supports Oracle 21c+, without a Hibernate persistence property being REQUIRED for such a case.

If I attempt using Hibernate 5.3+ (which is compiled against javax.persistence version 2.2) with jpaContainer-2.1, Hibernate scans for 2.2 package annotations as seen in the stack I posted above and fails EMF creation

[beikov]

Well, there also is no version of Hibernate built with JPA 2.1 that supports running on Java 11 out of the box, but we don't do releases of discontinued branches just because there is some new environment or database version. I understand that it is uncomfortable for you to do testing against this combination due to the need for dedicated configuration, but this is just how it is. There will be no new release for this branch.