On Fri, Jul 24, 2009 at 11:29 AM, Tom Ware <tom.ware@xxxxxxxxxx
<mailto: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
------------------------------------------------------------------------
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
