Re: [eclipselink-users] Expected merge behavior in lazycollectionfield w

[christopher delahunt <christopher.delahunt@xxxxxxxxxx>]

Hello Laird,

When detached, does an empty collection mean no changes, or that the 
collection was cleared?  If collections were merged into each other, 
there would be no way to remove or clear collections when using a 
detached object - all changes could only add to the collection on merge. 

You can use a query to obtain the 1:M results when they are needed and 
just cache it in the parent.  This would be similar to how a JPA 
provider implements it, only less efficiently without more complex code 
since with EclipseLink it can be cached in a shared cache and it can be 
invalidated/refreshed when appropriate. 

As Andrei mentioned, this isn't necessary - you can persist a new Child 
that references the Parent without actually changing the Parent's 
collection and still get the database to be updated correctly.  In such 
a case, because the Parent's collection of children will be stale (if 
triggered), the entire Parent object will need to be refreshed so that 
the new Children will also be read (lazily when required).  Only problem 
I can see is if you are using a provider that sets back references for 
you, since it could cause the collection to be triggered - such an 
option probably would need to be specified though and not be the default.

Best Regards,
Chris

Laird Nelson wrote:
> On Fri, Jul 24, 2009 at 1:43 PM, Andrei Ilitchev 
> <andrei.ilitchev@xxxxxxxxxx <mailto:andrei.ilitchev@xxxxxxxxxx>> wrote:
>
>     The spec. doesn't say what /supposed/ to happen in this case.
>
>
> Well, the spec /tries/ to.  It says that the state of the detached 
> entity is copied onto the state of the managed entity.  What's at 
> issue is: is the state the collection itself, or its contents?  The 
> spec is unfortunately unclear here.
>
> Regarding the bidirectionality of this relationship, yes, I'll 
> probably get rid of the one-to-many, although unfortunately it is 
> useful in other regards.
>
> Best,
> Laird
> ------------------------------------------------------------------------
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>