Eclipse Community Forums: EclipseLink

Help

Home

Home » Eclipse Projects » EclipseLink » Merge behavior

Show: Today's Messages :: Show Polls :: Message Navigator

Merge behavior [message #1071091]

Fri, 19 July 2013 06:29

Marco Quaranta
Messages: 3
Registered: July 2013

Junior Member

Hello,
I'd like to know if behaviour I'm going to explain is correct.
I've a Parent with several Collection<Child> relationship (@OneToMany, lazy fatch and no cascade).
Merging Parent makes Eclipselink executing several select statement, one for each child collections.

The code that issues these statements is in the method mergeIntoObject(Object target, boolean isTargetUnInitialized, Object source, MergeManager mergeManager, AbstractSession targetSession) class org.eclipse.persistence.mappings.CollectionMapping
in this line:

// BUG#5190470 Must force instantiation of indirection
containerPolicy.sizeFor(valueOfTarget);

Is this behavoir correct? I've experienced really low performance doing merge in this way.
My Eclipselink version is 2.3.2

Thanks,
Marco

[Updated on: Tue, 23 July 2013 03:19]

Report message to a moderator

Re: Merge behavior [message #1071292 is a reply to message #1071091]

Fri, 19 July 2013 15:10

Chris Delahunt
Messages: 928
Registered: July 2009

Senior Member

Are the collections on the object you are merging instantiated? If so, then it would need to trigger the collections on the managed entity to know what has changed for the merge operation.

Best Regards,
Chris

Report message to a moderator

Re: Merge behavior [message #1072199 is a reply to message #1071091]

Mon, 22 July 2013 05:22

Marco Quaranta
Messages: 3
Registered: July 2013

Junior Member

Hello Chris,
thank you for answering!

Collections on the object I'm merging are not instantiated (ie. references are null)...

However, I don't understand why entitymanager needs to trigger collections (instantiated or not) to know what has changed if I don't use cascade merge ...

Regards,
Marco

Report message to a moderator

Re: Merge behavior [message #1072742 is a reply to message #1072199]

Tue, 23 July 2013 08:09

Chris Delahunt
Messages: 928
Registered: July 2009

Senior Member

Null is not the same as not triggered, but changes to the list still must be merged into the collection. Cascade merge means that the merge will cascade to the referenced entities, the re fences themselves are a part of the entity being merged directly.

Report message to a moderator

Re: Merge behavior [message #1122159 is a reply to message #1071091]

Tue, 01 October 2013 05:29

Marco Quaranta
Messages: 3
Registered: July 2013

Junior Member

Hello Chris,
I'm returning on this after a while .. is this behaviour compliant with JPA Spec 3.2.4.1 Merging Detached Entity State?

"The persistence provider must not merge fields marked LAZY that have not been fetched: it must ignore such fields when merging."

It seems to me that merging my entity is eagerly loading every Collection<Child> even if these are marked as lazy and not fetched.

Thank you,
Marco

Report message to a moderator

Re: Merge behavior [message #1123386 is a reply to message #1122159]

Wed, 02 October 2013 10:08

Chris Delahunt
Messages: 928
Registered: July 2009

Senior Member

You said references are null, and I said null is not the same as not-fetched. How are they null? Null means they have been fetched or set to null, which means the merge process needs to trigger the collection on the managed entity to find out which entities are to be removed from the collection (through setting it to null).

Report message to a moderator

Previous Topic:	Can't get JPA properties passed through to DriverManager
Next Topic:	Reverse Engineering Legacy Database

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Mon Oct 07 16:33:02 EDT 2013