On DeleteOneToOneOrphansTest, setting Employee.employeeInfo to a new EmployeeInfo instance (instead of setting it to null) doesn't trigger the deletion of the old employeeInfo raising a ConstraintViolationException.
Please refer to the attached test suite patch.
This is somewhat related to HHH-4726.
The code below shows the two test cases I added to DeleteOneToOneOrphansTest.java from the hibernate-testsuite project.
The first one is pretty much the same as the already existing testOrphanedWhileManaged() but instead of setting Employee.employeeInfo to null, it is setting it to a new, unmanaged instance. It is expected that the previous EmployeeInfo instance would be deleted from the database since it is part of a one-to-one delete-orphan relationship.
The second one is similar, but forces a session flush after setting Employee.employeeInfo to null. It causes Hibernate to correctly issue a SQL DELETE and then, a SQL INSERT is issued due to the new EmployeeInfo instance associated. This can be seen as a workaround, but it would require the domain/business logic objects to deal with the Hibernate API directly.
Originally, I was going to change Cascade#cascadeProperty to attempt orphan removal when either child is null or the loadedValue != child (this case). However, the UK violation still occurs due to ActionQueue#executeActions executing inserts/updates before deletions. And it has to stay that way – deleting before updating can cause FK violations.
And, manually flushing (the delete, in this case) from within a cascade is a very bad idea.
, what's your opinion?
We just discovered that we're facing this issue using Hibernate 3.6.10.
Unfortunately we're stuck to Hibernate 3.6 as we're still forced to use Java 5.
Is there any possibility to get this fixed in 3.6 stream? Maybe a "private" patch?
Sorry, Hibernate 3 is no longer maintained