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