"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:
A (a self-referential Entity) is inherited by both B and C using Single_Table inheritance strategy.
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.
When persisting C1, an FK Violation is thrown.
In attached testcases
, 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
Activity
, is the foreign key violation a regression?
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.
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.
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.
Hi, have you consider to backport this fix to 5.3.X?
