On Fri, Jul 24, 2009 at 11:29 AM, Tom Ware
<tom.ware@xxxxxxxxxx> wrote:
I assume you have give this a try by now.
Actually no, not yet.
I beleive the behavior on EclipseLink will be that your merged parent will have 1 child.
OK. Drat. I'd like to be able to manage additions without having, first, to drag back all 10,000 children. I mean, I know I can do this myself; I was hoping there was some legal way to accomplish this in JPA. My thought initially was: look, if I really want to ensure that the elements of the collection are truly removed, then I should em.remove() each of them from that "side" of the @OneToMany relationship. That got me hopeful and I was thinking that maybe merging would cause the detached child collection to be merged into the loaded child collection. But I see that EclipseLink (and probably the spec) has in mind that the state of the detached entity's children is actually the collection itself, not the contents.
The way I interpret the spec is that there is a bit of leeway for persistence providers to do what they think is right in this situation. Here are the two parts I see relevant comments in.
(3.2.4.1) If X is a detached entity, the state of X is copied onto a pre-existing managed entity instance X'
of the same identity or a new managed copy X' of X is create
(3.2.4.2) Serializing entities and merging those entities back into a persistence context may not be interoperable
across vendors when lazy properties or fields and/or relationships are used.
<snip>
When interoperability across vendors is required, the application must not use lazy loading.
Indeed. The wrinkle here is that I'm replacing the collection, so whether lazy loading was used or not is irrelevant. The detached entity has a new collection of children, and so the question (not answered as far as I can tell by the spec) is: is the parent's state deemed to be the contents of its children or the children collection itself? I see that you've interpreted the spec to mean the latter.
Thanks for the response!
Best,
Laird
