On 26/09/2012 10:57, Jim Talbut wrote:
On 26/09/2012 10:19, Henno Vermeulen wrote:
Hi,

I verified this situation by making an extra unit test in our system. We always work with detached entities as well. The test works fine for me.

One explanation for this behavior is that the @OneToMany field does not use "fetch = FetchType.EAGER" because relations are lazily fetched by default. (Or alternatively you have not included the field in OpenJPA's FetchPlan before calling entityManager.merge which has the same effect as FetchType.EAGER even if the @OneToMany field is not eager).

When I adjust my test to lazily fetch the field, then saving a new Assessment somehow DOES cascade merge new AssessmentResults. However when I merge an existing Assessment that has one existing AssessmentResult and one new AssessmentResult, OpenJPA will not cascade merge it.

Thank you.
Yes, that is precisely what I'm going to be doing.
The results are large, so they are Lazy loaded, and the assessments are created in a different transaction - so the list is always empty when first loaded.

What I'm doing at the moment is, in the function that calls merge, iterating through the results and persisting any that aren't contained or detached. I have to do that first (before merging the assessment) or some results get persisted twice. This seems to be working (well, one of my unit tests passed, I've got other unit tests failing and that may not be related to this).

Jim

I've got that nearly all working now, but I've still got one big problem.

The detached entity that I create has two objects referring to it: one of which gets merged and the other gets persisted. The act of merging attaches the new entity, but replaces the variable the refers to it.
So when the other entity gets persisted I end up with a duplicate entity.

This is all caused by trying to break down big transactions into much smaller ones, which is why it's not the best structure.

Jim

Reply via email to