Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Talk:EclipseLink/Development/2.1/AdvancedJPA Queries/FetchGroup

Revision as of 11:10, 15 April 2010 by Douglas.clarke.oracle.com (Talk | contribs) (FetchGroup "Sparse" Merge)

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.
  • I am OK with this. --Doug 15:08, 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.
  • But this does not change the default behaviour as proposed by Andrei which is to merge based on the attached FetchGroup and ignore those attributes that were not fetched.
  • My intention is that any merge api native or EntityManager would have the same behaviour it currently does but has the additional constraint that it is limited to the fetched attributes as defined by the FetchGroup atatched to the entity implementing FetchGroupTracker. --Doug 15:10, 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.
  • 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.

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.
  • I believe we need a solution for 2.1 and at present this is what I have proposed. Users migrating to EclipseLink are looking for better solution for graph detachment (including serialization) with relationships. My preference is to add this to FetchGroup support versus adding another construct with overlapping functionality. --Doug 15:08, 15 April 2010 (UTC)

@FetchAttribute

  • Is the really required since it does not seem to do anything but have a name? Does it have any other attributes?

The current definition added to EclipseLink trunk (2.1) is:

@Target({TYPE})
@Retention(RUNTIME)
public @interface FetchGroup {
    /**
     * (Required) The fetch group name.
     */
    String name(); 
 
    /**
     * (Required) The list of attributes to fetch.
     */
    FetchAttribute[] attributes();
}

This additional annotation was defined to handle further qualification of the attribute.

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.

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)

Back to the top