The major part that altered this behavior comes from the introduction of the following if-block inside #cascadeLogicalOneToOneOrphanRemoval.
if ( valueEntry == null && loadedValue instanceof HibernateProxy ) {
loadedValue = eventSource.getPersistenceContext().unproxyAndReassociate( loadedValue );
valueEntry = eventSource.getPersistenceContext().getEntry( loadedValue );
}
What this block did not account for was that after the #unproxyAndReassociate invocation that there could be a possibility that child and loadedValue may point to the same instance, in which case we should not trigger the orphan removal; hence the additional if-check I mentioned in a prior comment to satisfy this use case. Beyond that, I cannot think of any other use case where this creates an issue. In fact, removing the above referenced if-block where we reassociate allows the user's test case to pass; however that does revert and break the fix we were accomplishing for
HHH-9663 Closed . So I think the extra if-check to compare the reassociated loadedValue with child to abort the cascade delete-orphan is the best of both worlds and shouldn't create any other issue. |