I know this a 'strange scenario' but due to an ongoing migration, I am using Eclipselink JPA (V2.5) but obtaining a UnitOfWork from the EntityManager using the implementation classes. I then delete an object using the uow:
The Object model is mapped using JPA XML mapping files, and I know the correct implementation is:
And I am 'lowly migrating a large code base to follow this design.
However, the two approaches give very different results! The XML mapping files state <cascade-all> and / or <cascade-remove> for all relationships. However, when using the uow to delete an object the removes are not cascaded, but when using the entityManager they are - orphan deletion still functions the same in both scenarios.
I don't know if this is a bug, because I don't know if the uow approach is actually supported. My goal is to convert all of the code base to use entityManagers, and the difference in behavior is actually working in my favour - because the existing (Native Eclipse legacy code) code behaves exactly the same as it did before regardless of whether <cascade-remove> is set or not, and we only need to consider remove semantics as the querying / manager bean code for each POJO is converted to proper JPA syntax
It is not a bug because the JPA contract forces a different cascade setting to be used than EclipseLink native api. JPA allowed setting mappings to cascade the delete using the CascadeType.Remove option, while EclipseLink native methods only delete objects referenced through privately owned relationships. So the native methods are left untouched, and new API with different contracts were added to support JPA and the new cascade type. Both are supported, but have the same functionality as JPA is using on the UnitOfWork, you will need to use the internal performRemove method.
Like I said, I like they way it currently behaves, and it means I don't have to change any of my xml mappings cascade settings until I migrate the individual manager beans that are doing the deletions.