ActionQueue#InsertActionSorter fails to generate right order:
Referential integrity constraint violation: "FKQ3H4GCPRJB128BSIUCBII8687: PUBLIC.SALEDOCUMENTITEM FOREIGN KEY(ID_SUBJECT) REFERENCES PUBLIC.OPERATIONREGISTRYSUBJECT(ID) (3)"; SQL statement:
insert into SaleDocumentItem (lp, product_id, quantity, ID_SALE_DOCUMENT, ID_SUBJECT, id) values (?, ?, ?, ?, ?, ?) [23506-176]
Because of https://hibernate.atlassian.net/browse/HHH-11634 we use 5.2.11-SNAPSHOT version which
I downloaded from Jenkins (http://ci.hibernate.org/view/ORM/job/hibernate-orm-master-pgsql/645/) but error also occurs in versions from issue's description
In tests hibernate.order_inserts=true which provoke error when I change to false everything works fine
Your entity mapping defines a circular dependency between SaleDocument and SaleDocuemntItem which causes this issue:
Well, that's just wrong because you can't delete a Child row because it might be referenced by a Parent and you can't delete the Parent row either because it's referenced by a Child.
So, due to the circular dependency, the inserts can not follow a parent-child ordering. You can only do that with manual flushing, but that's not possible to automate in Hibernate, and neither we should ever do that because the entity model is flawed.
So, you should never have such circular dependencies. Only SaleDocuemntItem should have a @ManyToOne association to SaleDocument while SaleDocument should use @JoinForumla as explained in this article.
1. main property has nullable = true so its optional
2. In hibernate 5.0.10 works
1. It does not matter, it's still a circular dependency.
2. In Hibernate 5.2.10, this works because there was a bug in the order_indert sorting mechanism.
I have no idea how to handle this circular dependency, but if you have an idea of how we should handle it without breaking all the other use cases, feel free to send a Pull Request.
Thanks for clarification,
currently without considering id's value, reordering only on classes and relations is impossible.
I need make some performance tests with reordering and without it, maybe reordering algorithm which includes all edge cases (like cycles) can take more time than performnce boost from jdbc batch