-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 
Author Message
 Post subject: FetchMode.SELECT triggers an "eager second select"
PostPosted: Wed Dec 13, 2006 5:13 pm 
Expert
Expert

Joined: Tue Dec 28, 2004 7:02 am
Posts: 573
Location: Toulouse, France
I guess this concerns H3.x. I'm posting this thread as a follow-up to this bug report : http://opensource.atlassian.com/project ... se/HHH-980

Someone was reporting that the javadoc of FetchMode.SELECT might be wrong asserting that the FetchMode.SELECT does fetch eagerly with a separate select : See http://www.docjar.com/docs/api/org/hibe ... tml#SELECT

I can't understand it. As I thought I'd understood : eager is the contrary of lazy, so here's what I asked Christian Bauer as a comment to the bug report :
Quote:
What's the meaning of lazy. I mean, I think I know it but, from what I understood, that's :

Say you have A which contains a list of B
* Retrieve A with a criteria query like session.createCriteria(A.class).setFetchMode("b",FetchMode.SELECT);
* close the session
* access a.getB() without receiving a LazyInitException ?

I just re-tried this use case and received a LazyInitException... Maybe I've not understood something, I'll certainly post a thread in the forum so as this behaviour can be explained further.

Is there some expert, or at least anybody that understands what the Hibernate team, and Christian here mean by speaking about an eager behaviour with setFetchMode("someRelation",FetchMode.SELECT)?

Thanks a lot for your help

_________________
Baptiste
PS : please don't forget to give credits below if you found this answer useful :)


Last edited by batmat on Sat Dec 16, 2006 9:03 am, edited 3 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 13, 2006 6:17 pm 
Expert
Expert

Joined: Fri Aug 19, 2005 2:11 pm
Posts: 628
Location: Cincinnati
http://www.hibernate.org/hib_docs/v3/re ... e-fetching

Quote:
Select fetching - a second SELECT is used to retrieve the associated entity or collection. Unless you explicitly disable lazy fetching by specifying lazy="false", this second select will only be executed when you actually access the association.


You need to find the right documentation, that's all =) This makes no mention of eager fetching. And eager fetching as you have described it is exactly correct.

It creates a second select statement when you access the collection, only your session is closed so you get that error.

I think you want Fetchmode.JOIN to retrieve it immediately. If you don't want a join, you keep the FetchMode.SELECT, and call a.getB() inside the session, or reassociate the object with a new session and call a.getB when needed.

_________________
Chris

If you were at work doing this voluntarily, imagine what you'd want to see to answer a question.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Dec 14, 2006 8:25 am 
Expert
Expert

Joined: Tue Dec 28, 2004 7:02 am
Posts: 573
Location: Toulouse, France
Quote:
I think you want Fetchmode.JOIN to retrieve it immediately.

Well, no. I know how to fetch data by using FetchMode.JOIN.

My point is just to try and understand what gavin and christian mean about the eager characteristic of FetchMode.SELECT as stated in the doc.

In fact, one week ago or so, I noticed this javadoc statement for FetchMode.SELECT : Fetch eagerly, using a separate select. Equivalent to fetch="select". As I thought it was a bug, I went to the JIRA and wanted to log a bug for it. But then I saw it had already been done AND REJECTED by gavin, asserting that there's in fact such a behaviour.

http://opensource.atlassian.com/project ... se/HHH-980

_________________
Baptiste
PS : please don't forget to give credits below if you found this answer useful :)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 15, 2006 4:36 am 
Newbie

Joined: Thu Dec 14, 2006 1:28 pm
Posts: 10
From what I know about subselect fetching and "eager" fetching, subselect fetching allows you to essentially load any and all collections of the containing object. When using eager by fetchmode.join, you can only load one collection with that efficiently. If you eagerly fetch all your collections using fetchmode.join, you create a cartesian product which is very inefficient. The subselect mode allows you to basically select the correct objects by their id's in another query that is transparent to you. I'm new to hibernate so I'm hoping I'm making the right assumptions.

Also, you cannot at the moment dynamically specify fetchmode.subselect, you can only specify it in the hbm.xml file using the "fetch=" attribute.

It would be nice to be able to dynamically set the fetchmode when loading an object with collections because then you can efficiently load an object graph without encountering the n+1 select problem.


You can check out this link which has some more info on fetching strategy and also the hibernate docs has info on it as well. Good luck.



http://www.javalobby.org/articles/hibernate-query-101/

Minh


Top
 Profile  
 
 Post subject:
PostPosted: Sat Dec 16, 2006 9:18 am 
Expert
Expert

Joined: Tue Dec 28, 2004 7:02 am
Posts: 573
Location: Toulouse, France
My only point is actually to understand why the javadoc is speaking about an eager behaviour. I already know the FetchMode.SELECT behaviour pretty well, 'cause I almost use it every day.

At the moment, I just think it should be fixed: removing the mention of the word "eager". But if I'm wrong, I'd really like someone to explain me that there's in fact this eager behaviour. If I'm right, have the javadoc comment fixed.

Moreover, it you put FetchMode.LAZY, which is actually deprecated, the doc says "Fetch lazily...". And if you look at the code, you see that LAZY uses the SELECT value, which speak about "eagerly" :-/. Quite diverting, particularly for hibernate newbies. (http://www.docjar.com/html/api/org/hibe ... a.html#x41)

_________________
Baptiste
PS : please don't forget to give credits below if you found this answer useful :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
cron
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.