[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Expected merge behavior in lazycollectionfield with CascadeType.MERGE, PERSIST?
|
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
