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

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

(Previous FetchGroup Functionality)
Line 1: Line 1:
 
= EclipseLink 2.1: Enhanced FetchGroup Support =
 
= EclipseLink 2.1: Enhanced FetchGroup Support =
  
This feature will enhance EclipseLink's existing FetchGroup support to include the following additional features:
+
This feature will make major enhancements to EclipseLink's existing FetchGroup support to extends its use beyond lazy loading of basics to encompass full graph definition and usage with queries (including find), detach/copy, and merge.
*
+
  
 
Related Bugs
 
Related Bugs
Line 9: Line 8:
 
__TOC__
 
__TOC__
  
== Previous FetchGroup Functionality ==
+
== Requirements ==
  
In 2.0 and earlier releases of EclipseLink FetchGroup had the following functionality:
+
The enhancement to FetchGroup support will include addressing the following requirements:
* Requires the entity class to implement FetchGroupTracker, which is generally only added during weaving.
+
 
* Supported single level attributes only
+
# Support defining FetchGroups that define what should be loaded including basic, embedded attributes, and relationships
* The attributes specified and required (identify and version locking columns) are read on the initial query
+
## Default FetchGroup for an entity type is defined based on the fetch (lazy loading) configuration of the attributes. For default FetchGroup only the attributes on the entity class itself and those available through inheritance are included.
* Requests for attributes not in the FetchGroup will be loaded together on a request for an un-fetched attribute (2 level load only).
+
## Named FetchGroup can be defined using Annotations (@FetchGroup), eclipselink-orm.xml, and API (typically in customizer). Only one named FetchGroup of a given name can exist for an entity type. Note: They can be overridden in inheritance hierarchies using the same name.
* Relationship attributes
+
## Dynamic FetchGroup can be specified to override
** 1:1/M:1 attributes in the FetchGroup will have their FK columns read
+
 
** Collection attributes ...
+
# FetchGroup can be used on any object-level query (ReadAllQuery, ObjectLevelReadQuery, JPA find)
 +
## If a FetchGroup is specified on a query directly or through the application of a JPA query hint it will be used and applied to the query result
 +
## If no FetchGroup is specified but a FetchGroup name is configured, either directly or through JAP query hint, then the named FetchGroup will be looked up through the descriptor and its parents hierarchy during query prepare and used if found. If not found an exception should be thrown
 +
## If no FetchGroup of FetchGroup name is specified on a query then the default FetchGroup looked up through the entity type's descriptor hierarchy will be used.
 +
## The FetchGroup specified, looked up by name, or looked up as default should not be cached in the query except during actual execution. This will allow FetchGroupManager changes to default and named FetchGroup to be used on subsequent query executions.
 +
## NICE TO HAVE: Add support for specifying the FetchGroup to use on an entity result in a composite select query where one of the ReportQuery's ReportItem is an entity type. Note: This support should be offered for all query optimizations (i.e. BATCH).
 +
 
 +
== Design ==
  
 
=== Configuration ===
 
=== Configuration ===

Revision as of 07:13, 24 February 2010

EclipseLink 2.1: Enhanced FetchGroup Support

This feature will make major enhancements to EclipseLink's existing FetchGroup support to extends its use beyond lazy loading of basics to encompass full graph definition and usage with queries (including find), detach/copy, and merge.

Related Bugs

Requirements

The enhancement to FetchGroup support will include addressing the following requirements:

  1. Support defining FetchGroups that define what should be loaded including basic, embedded attributes, and relationships
    1. Default FetchGroup for an entity type is defined based on the fetch (lazy loading) configuration of the attributes. For default FetchGroup only the attributes on the entity class itself and those available through inheritance are included.
    2. Named FetchGroup can be defined using Annotations (@FetchGroup), eclipselink-orm.xml, and API (typically in customizer). Only one named FetchGroup of a given name can exist for an entity type. Note: They can be overridden in inheritance hierarchies using the same name.
    3. Dynamic FetchGroup can be specified to override
  1. FetchGroup can be used on any object-level query (ReadAllQuery, ObjectLevelReadQuery, JPA find)
    1. If a FetchGroup is specified on a query directly or through the application of a JPA query hint it will be used and applied to the query result
    2. If no FetchGroup is specified but a FetchGroup name is configured, either directly or through JAP query hint, then the named FetchGroup will be looked up through the descriptor and its parents hierarchy during query prepare and used if found. If not found an exception should be thrown
    3. If no FetchGroup of FetchGroup name is specified on a query then the default FetchGroup looked up through the entity type's descriptor hierarchy will be used.
    4. The FetchGroup specified, looked up by name, or looked up as default should not be cached in the query except during actual execution. This will allow FetchGroupManager changes to default and named FetchGroup to be used on subsequent query executions.
    5. NICE TO HAVE: Add support for specifying the FetchGroup to use on an entity result in a composite select query where one of the ReportQuery's ReportItem is an entity type. Note: This support should be offered for all query optimizations (i.e. BATCH).

Design

Configuration

Mapping

API

JPA Query Hints

Back to the top