|
Is it "legal" for the client to install a new,
say, ArrayList<Child> into that field? As in: parent.setChildren(new
ArrayList<Child>() { { this.add(brandNewChild) } })?
Yes it
is.
Assuming that is legal (perhaps not a valid
assumption), suppose that back on the server tier we do an
EntityManager.merge(incomingParent), i.e. we merge the parent that has just had
this new collection installed on it. What is the expected state of the
Parent returned by the merge() operation? Should it have a children field
that, were we to load it, contains four Child entities? Or just the
one? That is, did the cascade operation stomp all over the previous
holistic value of the children Collection, or did it, well, merge in the new
Child?
After merge the parent should
contain the single brandNewChild.
----- Original Message -----
Sent: Wednesday, July 22, 2009 2:14
PM
Subject: [eclipselink-users] Expected
merge behavior in lazy collectionfield with CascadeType.MERGE, PERSIST?
Suppose I have a Parent with a Collection<Child>
relationship (@OneToMany), set up properly, with cascade = {
CascadeType.PERSIST, CascadeType.MERGE } at a minimum. And suppose that
I provide the ability to set this collection as well as get it:
public
Collection<Child> getChildren() { return this.children; }
public void
setChildren(final Collection<Child> children) { this.children =
children; }
Suppose further the client tier gets ahold of a detached
Parent, i.e. a Parent that was previously fetched from the database but is now
detached from the EntityManager. Suppose also that the Parent's children
field has not been accessed, and so has no items in it, but on disk, let's
say, it has three children. That is, if, on the server side, we had
invoked getChildren() we would have received--courtesy of lazy loading--a
Collection<Child> with three Child instances in it. But since we
didn't, no such load took place.
First question:
Is it "legal"
for the client to install a new, say, ArrayList<Child> into that
field? As in: parent.setChildren(new ArrayList<Child>() { {
this.add(brandNewChild) } })?
Second question:
Assuming that is
legal (perhaps not a valid assumption), suppose that back on the server tier
we do an EntityManager.merge(incomingParent), i.e. we merge the parent that
has just had this new collection installed on it. What is the expected
state of the Parent returned by the merge() operation? Should it have a
children field that, were we to load it, contains four Child entities?
Or just the one? That is, did the cascade operation stomp all over the
previous holistic value of the children Collection, or did it, well, merge in
the new Child?
I realize this is more of a specification question, but
EclipseLink is supposed to be the reference implementation, and all of my
specification questions that I've sent to the JSR feedback email address have
fallen into a black hole. Pointers to The Right Place Instead are
cheerfully accepted. Furthermore, I am planning on testing this in
EclipseLink, of course, but I'm more interested in what the specification
mandates than what EclipseLink might just happen to
do.
Best,
Laird
_______________________________________________
eclipselink-users
mailing
list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|
