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


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




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.


Vlad Mihalcea


Akarsh Jain

Fix versions





Suitable for new contributors


Requires Release Note


Pull Request





Affects versions