spacer spacer

View unanswered posts | View active topics


Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]



spacer  spacer  Page 1 of 1
 [ 7 posts ] 
  Previous topic | Next topic 
Author Message
pekarna
 Post subject: Setting LAZY or EAGER per-call, not per-class
spacer Posted: Sat Mar 14, 2009 2:08 am 
Newbie

Joined: Thu Jul 17, 2008 6:44 pm
Posts: 9
Hi,

LAZY or EAGER fetch strategy can be set for class member collection mapping.

However, in most cases, I would prefer to set fetching strategy for each distinct call of session manager API. I can't have everything as EAGER, because it would load whole DB. And having something LAZY forces me inevitably to 1+N SELECTs problem.

Please, is there any way to specify fetching type when calling e.g. find(...)?

Thanks,
Ondra


Top
 spacer  
 
spacer
ojm
 Post subject:
spacer Posted: Sat Mar 14, 2009 7:44 am 
Newbie

Joined: Wed Mar 04, 2009 6:36 pm
Posts: 8
Hi Ondra,

in HQL queries, you can use the "left join fetch" construct to specify that you want to eagerly fetch some association, independently of what is specified in the mapping file. E.g. you could issue the following query to eagerly fetch the "children" collection of a Person:
Code:
from Person p left join fetch p.children where p.id in (:ids)

Is this what you're looking for?

However, I don't know any way to change the fetching strategies when you are not using HQL but methods like Session#get and Session#load in which case only the settings in the mapping file are honoured.


Top
 spacer  
 
spacer
pekarna
 Post subject:
spacer Posted: Sat Mar 14, 2009 1:30 pm 
Newbie

Joined: Thu Jul 17, 2008 6:44 pm
Posts: 9
Thanks ojm,

The HQL tip is fine, but isn't exactly what I need.

I need to set fetching type for entities loaded using get() etc, as you wrote in the last paragraph.

Any further tips?


Top
 spacer  
 
spacer
kaizers
 Post subject:
spacer Posted: Mon Mar 16, 2009 7:27 am 
Newbie

Joined: Tue Dec 09, 2008 6:55 am
Posts: 12
Hi,

I'm looking for exactly the same thing but Hibernate allows the fetching strategy to be changed only through HQL or the Criteria API. I wish the load() or get() api could also accept a parameter specifying EAGER or LAZY loading. I really dont want to write separate HQLs to load eagerly and use the usual load api in other cases. It should be possible to do so using the same api.


Top
 spacer  
 
spacer
mmerder
 Post subject:
spacer Posted: Mon Mar 16, 2009 7:35 am 
Expert
spacer

Joined: Thu Jan 08, 2009 6:16 am
Posts: 661
Location: Germany
Its not possible to change the fetch-style for find().
However you could also use Criteria to change the fetch-style.

_________________
-----------------
Need advanced help? www.viada.eu


Top
 spacer  
 
spacer
kaizers
 Post subject:
spacer Posted: Mon Mar 16, 2009 7:39 am 
Newbie

Joined: Tue Dec 09, 2008 6:55 am
Posts: 12
Hi,

Thanks. But dont you feel it would be better to be able to do so through API? Instead of me having to write an HQL to fetch all my associations using joins, hibernate can do so internally if i pass the appropriate flag in load(). Currently, I need to have two mechanisms - use HQL or Criteria to fetch everything and load to lazy load.


Top
 spacer  
 
spacer
mmerder
 Post subject:
spacer Posted: Mon Mar 16, 2009 7:48 am 
Expert
spacer

Joined: Thu Jan 08, 2009 6:16 am
Posts: 661
Location: Germany
Yes, I also think it would be nice to manipulate the fetch-strategy at runtime.

Maybe there will be something like that in the next version.

_________________
-----------------
Need advanced help? www.viada.eu


Top
 spacer  
 
spacer
Display posts from previous:  Sort by  
spacer  spacer  Page 1 of 1
 [ 7 posts ] 

Board index » Hibernate & Java Persistence » Hibernate Users

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:
© Copyright 2015, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.