openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Russell (JIRA)" <>
Subject [jira] Commented: (OPENJPA-370) LoadFetchGroup annotation was not recognized during the fetch1
Date Mon, 29 Oct 2007 19:03:50 GMT


Craig Russell commented on OPENJPA-370:

I'm also concerned about the performance impact of the fix. 

The load fetch-group should not be a compute-intensive operation. It's meant to be a one-level
operation, not a multi-level or recursive operation.

The reason to use load fetch-group is to identify a fetch group to use when a field declared
as a lazy loaded field (not declared in a currently active fetch-group at the time the instance
it's a member of is fetched) is referenced. So it only applies when there is a requirement
to load an unloaded field. 

> 1) when a field X which is part of the loadFetchGroup L but it is not an eager fetch
field, field X can't determine whether it can be fetched or not because it is not sure that
the owner of this loadFetchGroup will be loaded . Therefore, we have to wait until the owner
of the loadFetchGroup is fetched. 

There is a difference between fetching a field and loading a field. Fetching a field is getting
it from the datastore. Loading a field is fetching a field that is not currently loaded. For
most operations (find, query, navigate) only the current fetch plan is needed to decide whether
a field is fetched or not (a simple union of all fetch-groups in the fetch plan, disregarding
the load fetch-group. The only time the load fetch-group is used is for field access operations
where the instance is in memory but the field wasn't fetched before. This is due to one of
two reasons: the instance is hollow and a field is accessed; the instance is not hollow and
a field is accessed that wasnt' part of the fetch plan when the instance was fetched.

> 2) when a field Y has a FetchGroup associated with , then field Y is required to fetch.

>   ==> Then we need further to check whether this field Y has any loadFetchGroup. If
field Y has a loadFetchGroup L; then we need to get the fields that associate with L. 

I'm not really following this argument. The relevant part of the specification (JDO) is:

When the application dereferences an unloaded field, the JDO implementation uses the current
fetch plan and the load-fetch-group of the field to create the fetch strategy for the field.
The specific behavior depends on whether the unloaded field is a relation to another persistence-capable
for non-relation fields, the current fetch plan is applied to the field's owning instance,
and the fields in the field's load-fetch-group, plus the field itself are added to the list
of fields.
for relation fields, the fields in the owning instance are fetched as immediately above, and
additionally the instances referred by the field are loaded using the current fetch plan plus
the field's load-fetch-group.

>From the discussion, it sounds like patch 1 is more appropriate to implement the intent.

> LoadFetchGroup annotation was not recognized during the fetch1
> --------------------------------------------------------------
>                 Key: OPENJPA-370
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 1.0.1, 1.1.0
>            Reporter: Teresa Kan
>            Assignee: Teresa Kan
>             Fix For: 1.0.1, 1.1.0
>         Attachments: OPENJPA_370_2.patch,
> Employee class has a LoadFetchGroup annotation defined on the Rating field, when getRating
was called, the address should be returned also. However, openjpa did not handle the LoadFetchGroup
correctly, therefore, address was not eargly fetched.
> public class FGEmployee{
>     @Id
>     private int id;
>     @OneToOne(fetch=FetchType.LAZY) 
>     private FGAddress address;
>     @Basic(fetch=FetchType.LAZY)
>     @LoadFetchGroup("AddressFetchGroup")
>     private String rating;
>     @ManyToOne(fetch=FetchType.LAZY)
>     private FGManager manager;
> ..
> }

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message