Joined table values not persisted when using JOINED JPA inheritance after upgrade beyond 5.2.12

Description

I have the following defined entities:

When using any Hibernate version above 5.2.12 we are experiencing a strange behavior once transaction is committed after persisting an entity - only the common fields are persisted - the "JOINED" part is not. Thus, if attempting to retrieve the persisted entity by its assigned ID we are getting null. An inspection of the actual database table confirms this is the case: the common fields exist for the persisted assigned ID, but the JOINED part is missing

Here is where it is really getting interesting - there are other entities in the (same) system that used JOINED inheritance - and there it does not seem to happen. The only difference between the working ones to the failed ones is that the failed ones (i.e., the ones mentioned in this issue) also extend a @MappedSupperclass

Other than that, I can see no other difference.

As mentioned, this started happening as of 5.2.13 and up.

Environment

OpenJDK 8 build 171
Spring Data Kay-SR6
QueryDSL 4.2.1
Fedora 27

Activity

Show:
Lyor Goldstein
July 23, 2018, 12:38 PM

You may have a point - I will attach the code for EntityTimestampsTrackingListener

Lyor Goldstein
July 23, 2018, 12:52 PM

See https://github.com/lgoldstein/hibernate-test-case-templates/tree/HHH-12641 it contains all my latest test code - including the EntityTimestampsTrackingListener. Specifically, see org.hibernate.bugs.JPAUnitTestCase

Lyor Goldstein
July 23, 2018, 2:02 PM

to the best of my knowledge the attached files contain the full definition of the entities in question

I mis-spoke - I meant that these entities are as close as possible to the original definitions (98%) - I wish I could bring the exact code, but it involves many other definitions. I tried to keep it as close as possible to the original without compromising (AFAIK) the JPA mapping. In any case, now that we have my test code framework perhaps it might be easier to try stuff out...

Guillaume Smet
July 23, 2018, 2:25 PM

we can't guess what the problem is. Yoann tried to reproduce it to no avail and apparently you did too.

So maybe you should try to reproduce it with your Spring + C3P0 layer. It might be a transaction manager issue or something related.

It might also be due to some Hibernate configuration that Spring enables automatically.

Lyor Goldstein
July 24, 2018, 5:06 AM

Indeed seems a tricky issue - thanks for the effort. I will see what I can do (within the limited time I have to spend on this issue) to further clarify the problem. Meanwhile, I think I will use the workaround - i.e., use a dedicated sequence instead of IDENTITY. If I find out anything else that might be of help I will update this issue.

Assignee

Unassigned

Reporter

Lyor Goldstein

Fix versions

Labels

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Feedback Requested

2018/06/13

Worked in

5.2.12

Feedback Requested By

Christian Beikov

Components

Affects versions

Priority

Major
Configure