Sorry, I was wrong.
After the merge the attached parent indeed will have a
new collection containing just new child,
but if you refresh the parent it will have four children - all
old ones and the new one.
So if you don't want to trigger the collection on the attached
parent, instaed of merging into parent just persist the newChild (of
course it should reference the parent).
----- Original Message -----
Sent: Friday, July 24, 2009 2:32 PM
Subject: Re: [eclipselink-users] Expected
merge behavior in lazycollectionfield with CascadeType.MERGE, PERSIST?
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
_______________________________________________ eclipselink-users
mailing
list eclipselink-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|