- Hibernate ORM
- HHH-3414
fetch profiles
- Log In
-
Views
- XML
- Word
- Printable
Details
-
Type: New Feature
-
Status: Open
-
Priority: Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: core, metamodel
-
Labels:None
-
Requires Release Note:Affirmative
Description
The concept of fetch profiles as we are discussing here is basically to allow users to dynamically affect the mapped fetching strategy for associations at runtime.
Consider the following example:
<class name="Person">
...
<set name="addresses" lazy="true" fetch="subselect" ...>
...
</set>
</class>
<class name="Address">
...
</class>
This follows the normal recommendation to map associations as lazy and use a dynamic fetching strategy (ala HQL/Criteria) to modify this lazy behavior at runtime.
The fetaure discussed here would allow the same behavior for loading as well:
<hibernate-mapping>
<fetch-profile name="person-details">
<fetch path="Person.addresses" style="join"/>
</fetch-profile>
</hibernate-mapping>
Or:
<hibernate-mapping>
<class name="Person">
...
<fetch-profile name="person-details">
<fetch path="addresses" style="join"/>
</fetch-profile>
<set name="addresses" lazy="true" fetch="subselect" ...>
...
</set>
</class>
</hibernate-mapping>
Now, doing:
session.enableFetchProfile( "person-details" ).get( Person.class, 1 )...
will load Person#1 as well as their addresses in a single joined query.
- Options
- Show All
- Show Open
Sub-Tasks
1. |
Phase 1 - API & implement join-strategy | |
Closed
|
Steve Ebersole | |
| 2. | Phase 2 - implement rest of strategies | |
Open
|
Steve Ebersole |
Activity
-
All
Comments
Work Log
History
Version Control
Activity
Commits
It would be nice to be able to do be able to control things at this level too for formula based properties. These can contain expensive SQL queries and it would be nice to be able to set the fetch mode on such a lazy formula property so it is either retrieved via select (n+1) or fetched non-lazily (equivalent to join).
You could then enable these expensive formula properties only when needed.
I think you are trying to describe what are generally called fetch groups. This is in fact possible today (though in a limited fashion : with only a single fetch group) using Hibernate's bytecode enhancement tasks.
Forum discussion of similar subject:
forum.hibernate.org/viewtopic.php?p=2408827
It might be a good idea to be able to extend a fetch profile so that one need not redefine the same fetch paths repeatedly. For eg.
<fetch-profile name="person-details">
<fetch path="Person.addresses" style="join"/>
</fetch-profile>
<fetch-profile name="person-education-details" extends="person-details">
<fetch path="Person.educationdetails" style="join"/>
</fetch-profile>
for its contents. This is a safe-cache copy of the original web site.
Types of fetches:
1) join - an outer join fetch
2) select - a subsequent select fetch (n+1)
3) subselect - support for this requires significant refactoring to the subselect loading code, and as such it is not planned for the initial feature release.