[
https://issues.apache.org/jira/browse/OPENJPA-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538561
]
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:
<spec>
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 class.
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.
</spec>
>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: https://issues.apache.org/jira/browse/OPENJPA-370
> 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, TestFetchGroup.zip
>
>
> 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.
