4:39 p.m.
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate3
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.4
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:46 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
Steve Ebersole commented on HHH-3414:
-------------------------------------
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.
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate3
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.4
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:26 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
Gary Sargent commented on HHH-3414:
-----------------------------------
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.
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate3
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.4
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:58 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
Steve Ebersole commented on HHH-3414:
-------------------------------------
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.
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate3
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.4
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:17 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
Ondra Žižka commented on HHH-3414:
----------------------------------
Forum discussion of similar subject:
http://forum.hibernate.org/viewtopic.php?p=2408827
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate Core
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.5
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:32 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
Kaizer commented on HHH-3414:
-----------------------------
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>
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate Core
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.5
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:40 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
Steve Ebersole commented on HHH-3414:
-------------------------------------
My issue with allowing "extension" of fetch profiles is what Hibernate terms
"second passes". Basically, every time we encounter an extends we have to
account for the possibility that the thing extended is not yet defined (forward
references). It adds complexity and overhead to the process. And is it really worth it?
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate Core
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.5
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:14 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
Steve Ebersole updated HHH-3414:
--------------------------------
Fix Version/s: (was: 3.5)
3.7
See the new subtasks
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate Core
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.7
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:01 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
savio commented on HHH-3414:
----------------------------
Is it planned that HQL would honor the fetch-profiles ? I ask since currently HQL is not
designed to honor the fetch="join" in hbm/cfg
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate Core
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.7
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:58 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
Paul Benedict commented on HHH-3414:
------------------------------------
I definitely believe this is an important feature. Especially if the fetch profiles can be
enabled outside a criteria or hql -- such as at the session level. I would like to see
something like session.setFetchProfile(MyEntity.class, profileName).
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate Core
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.7
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:44 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
Paul Benedict commented on HHH-3414:
------------------------------------
Fetch profiles aren't a necessity, but it is one solution to the problem. One issue
that I have with Hibernate is that Criteria and HQL allow queries to be more eagerly in
their fetch strategies (setFetchMode), but you can't relax it. Once something is
mapped as eager, it cannot be undone. This is where the deprecated FetchMode.LAZY could
make a nice return.
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate Core
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.7
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:08 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
Darren Bell commented on HHH-3414:
----------------------------------
Just an observation, but should setFetchProfile(profileName) be at the Criteria and Query
level? This would allow my daos to have the same session, but retrieve diffrerent
profiles per query.
For example, I have a dao which subclasses another dao and which overrides the returned
entity via covariance. Each dao could then be set to a different fetch profile.
Does this make sense?
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate Core
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.7
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:54 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
Steve Ebersole commented on HHH-3414:
-------------------------------------
@savio : yet to be determined long term. as of now it follows the same rules as metadata
fetching: HQL ignores while criteria honors. I'd much prefer any changes to be
symmetric.
@Paul : yes, but this is exactly why it is recommended that you map associations as lazy
and use various use-case based fetching (previously hql/criteria fetches, but now these
fetch profiles too). Making something you mapped as non-lazy suddenly lazy for a
particular use-case is not coming back. And yes, fetch profiles are enabled on the
Session. That's the idea.
@Darren : see above.
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate Core
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.7
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:56 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
Steve Ebersole updated HHH-3414:
--------------------------------
Fix Version/s: (was: 3.x)
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate Core
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:17 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414?page=c...
]
Sebastien Tardif commented on HHH-3414:
---------------------------------------
It's hard to write complex software without this feature. I'm used to software
that nobody understand more than 30% of the use cases, and the workflows then to make an
infinite set of different calls against the domain objects and DAO. I'm surprise this
is still not yet fixed, and how the user are able to cope without it.
http://webspherepersistence.blogspot.com/2009/02/dynamic-fetch-planning.html
http://openjpa.apache.org/builds/latest/docs/manual/ref_guide_fetch.html
Other similar framework still didn't code that yet:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=310817 &
https://bugs.eclipse.org/bugs/show_bug.cgi?id=305020
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate Core
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:46 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
https://hibernate.onjira.com/browse/HHH-3414?page=com.atlassian.jira.plug...
]
Tedi Zanfolim commented on HHH-3414:
------------------------------------
FetchProfiles won't work if multiple fetchOverrides referring to multiple bags are
specified. It seems multiple bags are not supported in the join strategy, which is
probably a bad idea since it might cause a huge Cartesian product. Anyway, it would be
nice to get an error message, instead of only the first collection getting loaded.
For the record, the mapping below will just load roles, without ever complaining that
emails won't be eagerly loaded.
@FetchProfile(name = "Person-all", fetchOverrides = {
@FetchProfile.FetchOverride(entity = Person.class, association = "roles",
mode = FetchMode.JOIN),
@FetchProfile.FetchOverride(entity = Person.class, association = "emails",
mode = FetchMode.JOIN),
fetch profiles
--------------
Key: HHH-3414
URL: https://hibernate.onjira.com/browse/HHH-3414
Project: Hibernate ORM
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:56 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3414) fetch profiles
[
https://hibernate.onjira.com/browse/HHH-3414?page=com.atlassian.jira.plug...
]
Steve Ebersole commented on HHH-3414:
-------------------------------------
Tedi, this is true in all cases for attempts to fetch multiple bags. There is another
issue in JIRA that details what I would eventually like to do in terms of semi-allowing
this. Basically instead of join fetching we'd silently fall back to subselect
fetching. But there are a lot of pre-req changes that have to happen to get there.
fetch profiles
--------------
Key: HHH-3414
URL: https://hibernate.onjira.com/browse/HHH-3414
Project: Hibernate ORM
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4700
days inactive
5984
days old
hibernate-issues@lists.jboss.org
16 comments
9 participants
participants (9)
-
Darren Bell (JIRA) -
Gary Sargent (JIRA)
-
Kaizer (JIRA)
-
Ondra Žižka (JIRA)
-
Paul Benedict (JIRA)
-
savio (JIRA)
-
Sebastien Tardif (JIRA)
-
Steve Ebersole (JIRA)
-
Tedi Zanfolim (JIRA)