Difference between revisions of "Talk:EclipseLink/Development/2.1/AdvancedJPA Queries/FetchGroup"

Revision as of 11:00, 15 April 2010

FetchGroup Copy

• Session already has a copyObject() API, this should just be exposed on the JpaEntityManager interface and allow an optional FetchGroup argument. I am not a fan of having static Helper objects, but using our public interface and the standard JPA 2.0 unwrap API.
  • James.sutherland.oracle.com 13:36, 15 April 2010 (UTC)

FetchGroup "Sparse" Merge

• The UnitOfWork merge() APIs should be exposed on our JpaEntityManager interface (shallowMerge, deepMerge, merge(Object, FetchGroup). I am not a fan of having static Helper objects, but using our public interface and the standard JPA 2.0 unwrap API.
  • James.sutherland.oracle.com 13:36, 15 April 2010 (UTC)

EntityFetchGroup

• I don't see the reason for having an EntityFetchGroup. The Entity should just hold the FetchGroup from the query (which should be cached in the query). If the Entity needs to add something to the fetch-group it should first copy it, perhaps have a shared flag in the FetchGroup if required.
  • James.sutherland.oracle.com 13:36, 15 April 2010 (UTC)

• The purpose of the EntityFetchGroup is to address:
  1. Entity specific FetchGroup state separate from the shared FetchGroup so that setting un-fetched attributes augments the FetchGroup versus loading all of attributes as well as a means to handle merged/union of FetchGroups for overlapping reads.
  2. Serialization: The EntityFetchGroup could handle specialized serialization so that its detached version holds the complete set of fetched attributes
• Using a single FetchGroup with lazy cloning for these cases is also possible.

--Doug 14:59, 15 April 2010 (UTC)

Refreshing

• There should be some way to refresh a partial object and have the version updated. A normal query should union the two fetch groups and not refresh the version. A refresh query should not union the fetch groups but use the new one only, and refresh the version. Otherwise, there is no way to refresh a stale object without fetching the object in its entirety.
  • James.sutherland.oracle.com 13:36, 15 April 2010 (UTC)

Serialization, instantiation

• I do not think fetch groups should be coupled with serialization support. Serialization support is something that any user serializing requires, and should not require the usage of fetch groups. We should have a separate option on query to force instantiation of a set of attributes. Fetch groups and join fetching could have an option to automatically add their relationships to this separate option. The instantiation must be implemented very carefully to avoid cache deadlocks.
  • James.sutherland.oracle.com 13:36, 15 April 2010 (UTC)

@FetchGroupAttribute

• Is the really required since it does not seem to do anything but have a name? Does it have any other attributes?
  • James.sutherland.oracle.com 13:36, 15 April 2010 (UTC)

Attempts to access unfetched attributes will cause an exception to be thrown

• Our indirection support can load results within a detached object. Our FetchGroup support should be able to do the same.
  • Gordon.yorke.oracle.com 14:53, 15 April 2010 (UTC)

The requirements I am getting is that unfetched attributes in detached/serialized objects be null and not a proxy load mechanism. --Doug 15:00, 15 April 2010 (UTC)