[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Expected merge behavior in lazy collection field with CascadeType.MERGE, PERSIST?
|
Hi Laird,
I assume you have give this a try by now. I beleive the behavior on
EclipseLink will be that your merged parent will have 1 child.
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.
-Tom
Laird Nelson wrote:
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
