"order_inserts = true" causes FK Violation when inserting Self Referential Entity with Single_Table Inherited Entities

Description

In a particular case as described below, order-inserts = true causes FK Violation, while order-inserts = false does not:

  1. A (a self-referential Entity) is inherited by both B and C using Single_Table inheritance strategy.

  2. We have created entites as so: C1 -> B1 -> C2 -> A1, where C1, C2, B1 and A1 are entities of types C,C,B and A respectively.

  3. When persisting C1, an FK Violation is thrown.

  4. In attached testcases

  1. , it is also observed that the order of inserts of some entities referred to by A,B or C gets ruined and causes FK violations different from observed with above case.

Above cases work just fine for order-inserts = false.
Both above cases are included in the attached test cases. Is this a limitation of the order_inserts feature, a bug or am I missing an accepted workaround?

Edit: Was reported in 5.2.8.final, tested in 5.2.17, 5.3.1 and 5.3.7 and same test cases failed in all versions.
Failing test cases are:
Tests in error:
InsertSortingTest1(org.hibernate.bugs.JPAUnitTestCase): Error while committing the transaction
InsertSortingTest3(org.hibernate.bugs.JPAUnitTestCase): Error while committing the transaction
InsertSortingTest6(org.hibernate.bugs.JPAUnitTestCase): Error while committing the transaction
InsertSortingTest9(org.hibernate.bugs.JPAUnitTestCase): Error while committing the transaction

Environment

None

Activity

Show:
Vlad Mihalcea
January 17, 2019, 8:23 PM

This fix allows us to skip the sorting when we detect a dependency cycle, which is more like an improvement than a regression.

The use case provided in the test case is very unusual since there are many dependency cycles between associations and across the inheritance tree, and the fix manages to make all those test cases to pass.

So, if we are to back port it, we can do it to 5.3, 5.2 and 5.1 as well.

Gail Badner
January 18, 2019, 10:01 AM

, is the foreign key violation a regression?

Vlad Mihalcea
January 18, 2019, 11:14 AM

I don't think so. A regression would mean this worked before. I’m not sure if this use case here was ever supported or that it was caused by a commit done recently.

Marko Mitrović
January 18, 2019, 11:56 AM

From my experience, this worked ok in 5.2.2, and did not work in 5.3.7. I'm not sure for versions between those two.

Vlad Mihalcea
January 18, 2019, 12:23 PM

Thanks, Marko for the pointer.

I tested the test case provided for this issue with various versions of 5.2, and it seems that it was working up until 5.2.3, and the issue appeared in 5.2.4.

So, indeed, it is a regression. After checking the release note, I think it's due to HHH-9864.

Therefore, it's good to backport it to 5.3, 5.2, and 5.1.

Assignee

Vlad Mihalcea

Reporter

Akarsh Jain

Fix versions

Labels

None

backPortable

Backport?

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure