GenerationType.AUTO not checking database provider and never using org.hibernate.id.IdentityGenerator

Description

Hibernate method org.hibernate.boot.internal.IdGeneratorInterpreterImpl.FallbackInterpreter.determineGeneratorName has switch case with following default:

I don't know if this is intentional, but as JPA documentation says about GenerationType.AUTO:

"Indicates that the persistence provider should pick an appropriate strategy for the particular database."

It seems the current implementation does not in any way check what kind of database it is using and whether or not the database supports identity generation. GenerationType.AUTO works correctly in Hibernate 3.5.6-Final and while I understand that the major number has changed and therefore there is no guaranteed backwards compatibility, this seems quite a big leap to take.

Attached is a test case that can be used to verify the problem. Running mvn clean package on project root should run AbstractHibernateEntityDAOInsertNewTest which should fail. The test has AbstractHibernateEntityDAOInsertNewTest-dataset.xml defining single entity persisted into database. The test tries to persist another entity and fails because Hibernate is using org.hibernate.id.enhanced.SequenceStyleGenerator which always gives the new entity id 1 totally oblivious of the fact that there is persistent entity with that id.

So when running Hibernate 5.0.3.Final the test fails and logs out following:

2015-11-04 10:59:48 DEBUG SqlStatementLogger.java:92 insert into EntityWithName (created, deleted, modified, version, name, id) values (?, ?, ?, ?, ?, ?)
Hibernate: insert into EntityWithName (created, deleted, modified, version, name, id) values (?, ?, ?, ?, ?, ?)
2015-11-04 10:59:48 TRACE BasicBinder.java:64 binding parameter [1] as [TIMESTAMP] - [Wed Nov 04 10:59:48 EET 2015]
2015-11-04 10:59:48 TRACE BasicBinder.java:52 binding parameter [2] as [TIMESTAMP] - [null]
2015-11-04 10:59:48 TRACE BasicBinder.java:64 binding parameter [3] as [TIMESTAMP] - [Wed Nov 04 10:59:48 EET 2015]
2015-11-04 10:59:48 TRACE BasicBinder.java:64 binding parameter [4] as [INTEGER] - [0]
2015-11-04 10:59:48 TRACE BasicBinder.java:64 binding parameter [5] as [VARCHAR] - [two]
2015-11-04 10:59:48 TRACE BasicBinder.java:64 binding parameter [6] as [INTEGER] - [1]

There are two workarounds, either
A) set Entity.id to use GenerationType.IDENTITY
B) stab Hibernate code to always return IdentityGenerator.class.getName(); from IdGeneratorInterpreterImpl.FallbackInterpreter.determineGeneratorName when switch goes into default.

When using either of these workarounds, the test passes and gives following log:

2015-11-04 10:56:16 DEBUG SqlStatementLogger.java:92 insert into EntityWithName (id, created, deleted, modified, version, name) values (default, ?, ?, ?, ?, ?)

2015-11-04 10:56:16 TRACE BasicBinder.java:64 binding parameter [1] as [TIMESTAMP] - [Wed Nov 04 10:56:16 EET 2015]
2015-11-04 10:56:16 TRACE BasicBinder.java:52 binding parameter [2] as [TIMESTAMP] - [null]
2015-11-04 10:56:16 TRACE BasicBinder.java:64 binding parameter [3] as [TIMESTAMP] - [Wed Nov 04 10:56:16 EET 2015]
2015-11-04 10:56:16 TRACE BasicBinder.java:64 binding parameter [4] as [INTEGER] - [0]
2015-11-04 10:56:16 TRACE BasicBinder.java:64 binding parameter [5] as [VARCHAR] - [two]
2015-11-04 10:56:16 DEBUG IdentifierGeneratorHelper.java:74 Natively generated identity: 2

Is the current functionality by design or by mistake?

Environment

None

Activity

Show:
Steve Ebersole
November 6, 2015, 3:21 AM

IDENTITY generation causes a lot of problems. So for AUTO we decided to use a "sequence style generator" across all databases for consistency. Which is well within the bounds of JPA. If you would like Hibernate to use IDENTITY, then select IDENTITY.

Assignee

Unassigned

Reporter

Jukka Hämäläinen

Fix versions

None

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Critical
Configure