[
https://issues.apache.org/jira/browse/OPENJPA-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Teresa Kan updated OPENJPA-370:
-------------------------------
Attachment: OPENJPA_370_2.patch
I redo the fix for the LoadFetchGroup. The basic fix is based on the following
principles:
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.
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 have been looking into how to capture the info at parser phase. For example,
if this is a LoadFetchGroup, then it should know all the fields that associated
with this group. However, I found out that the fetch group is a String of name
in the FieldMetaData. Unless we change the design to use the real FetchGroup
object instead of the name, then we can capture the data at parsing time.
Anyway, I used the existing design and implementation to change the code. I
have two patches:
1) Patch 1 :
It adds the LoadFetchGroup to the current active fetchgroup once it is found
that the owner has defined this LoadFetchGroup, then StateManagerImpl will
remove it later once all the fields are loaded.
2) Patch 2:
StateManagerImpl let the FetchConfiguration figure out what fields are needed
to fetch for any fetch group. Instead of going to the
FetchConfiguration.requiresFetch one field at a time, I introduced a new method
FetchConfiguration.requiresFetch(set fetchgroup, FieldMetaData[] fmds) to
return all the fields for the fetch groups.
FetchConfiguration.requiresFetch() gets all the fields from the new
includes(fetchgroup, fmds) method. This method loops thru each field and checks
whether it associates with an active fetchgroup. If it is, then checks for a
loadFetchGroup. If this field has the LoadFetchGroup, then get all the fields
that associate with this LoadFetchGroup from getLoadFetchGroupFields().
The getLoadFetchGroupFields() basically walk thru each field to check whether
it is part of this LoadFetchGroup. Once all the fields are found, saved it in a
cached Map for future use.
Now we need to make decision about which patch should we use:
Patch 1 is simple and less expensive ; but it does not fit well into the
architecture. Patch 2 is kind of fit well with the architecute but it is more
expensive. Although I cached the loadFetchGroupFields info, we still need to go
thru once to build this cache.
The best solution is to make use of the FetchGroup object. During the parse
phase, capture the fields info in the FetchGroup. In addition to capture the
fetch group info in the Field, each FetchGroup also captures the fields info.
In this case, once we find a fetch group, we can get all the loadFetchGroup and
its assocated fields info.
Since I'm not totally familiar with the code, so it will take me a while to
redo the FetchGroup objects in the parse phase. My suggestion is to commit
either the patch1 or patch 2 in the version 1.0.x first. Then continue to work
on the real implementation in 1.1.0.
> 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.1.0
> Reporter: Teresa Kan
> 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.
