Hi,

I am using Hibernate version 3.1.3.

I load some "folder items" through a global outer join and in the returned data, there are some associated data, called sections.

Not all sections' associated values are also loaded through this first global outer join.

Each section owns a set of element items and each element item owns also a set of synonyms : section=>element=>synonym.

In Section.hbm file :




In Element.hbm file :



What I want: when I call section.getListeElements().size() many times, I want that Hibernate loads the synonyms associated with the element items and produces the following outer join :

select ... from t_element, t_synonyme where id_element in (?, ?, ?...?)

* 1st idea : fetch="join" in Element.hbm file. But Hibernate does not care.

* 2nd idea : lazy="false" in Synonyme.hbm file. But Hibernate does not care also.

Hibernate reacts only to the batch information, but not to my efforts ("oujer join") to tell it to load the synonymes with the element items.

One may say "outer join" and batch actions don't play well together.

Anyone has an idea ?

Many thanks.

Regards,
Dominique

Have you fixed a value for the hibernate.max_fetch_depth property?

I dont know if the default value is 0 or 1. For your case, I think you need a value of 2 or more.

Ooops, I've forgotten to write, I have already set the property you mention:



plus, the following:



Any other idea ?

Thanks.

Regards,
Dominique

Hi ,
I believe if you either set Lazy= false or if you are iterating in the same session you should able to get all the elements.
Thanks,

I have already used lazy="false" (see my second idea above) and I am already iterating in the same session. The point is not to get the elements, but the elements, plus the synonyms into a single "outer join" with batch processing.

Anyway, thanks for your help.

Any other idea ?

If i understand correctly, you have loaded folder items. Then you need to access

a set of folder
and then a set of sections for the folders
and then a set of elements for the sections
and then a set of synonyms for the elements

maybe you need a max_fetch_depth of 4

First all, many thanks for your replies! I appreciate.

You made me wondering if I was wrong about max_fetch_depth. So, I have set it to 10, and the problem is still here.

Let me point here some details.

I do an outer join like this one :



Then, I do in Java :



Elements associated with each section are loaded, with batch processing. But the fetch="join" + lazy="false" in the Element.hbm are ignored :



I "just" want batch processing while element items PLUS associated synonym items gathered into a single outer join. But while trying to do batch processing and fetch="join", Hibernate is ok with batch and it looks like it does not care about fetch="join".

Hi ,
Are you getting any error at all when you iterate over the child elements. Are you using the right data which had all these elements.
I dont see any problems in your code at all.
If you get any error can you please post it.I doubt your data got the issue.
Thanks,
Vinodh

Hi ,
Are you getting any error at all when you iterate over the child elements. Are you using the right data which had all these elements.
I dont see any problems in your code at all.
If you get any error can you please post it.I doubt your data got the issue.
Thanks,
Vinodh

Hi Vinodh,

Thanks for your help.

Well, no error appears. This point is simply that Hibernate does no react as expected.

Hibernate executes the following query for getting (1) element items:



then, Hibernate is generating a bunch of queries like the following one to get (2) the synonyms associated with previous element items:



The point is I expect an outer join between the 2 tables t_element and t_synonym as I have defined fetch="join" (see above). I expect a query like the following one :



But Hibernate does not care about fetch="join".

Any idea ?

could you complete the hql ?

The complete HQL request is:



And I do after:


Each folder links to all associated sections and all associated formularies.
Each section links to the formulary it belongs.

Then, I do the following in Java as explained above:



I may do a global outer join including folder, section, formulary, and also elements and synonyms. But there is much, much more elements than folders, sections, and formularies.

So, my strategy is the following:
- first, load folders, sections, and formularies in a single outer join,
- secondly, call "Hibernate.initialize(section.getListeElements());" to fetch associated sections' data. These associated data are element and synonym items (section=>element=>synonym). And I want to fetch element and synonym with outer join and batch processing

Thanks for any help.

This is normal behaviour: if your HQL is not good, then it won't work. In fact, HQL overrides any settings in the hbm.xml file. Try doing your query in Criteria to see if it works better. Criteria will use by default the hbm settings. You can redefine them by using setFetchMode() on your query.

Thanks for your reponse Baptiste.



The HQL works as expected. The pb arises when navigating from the returned objects: that is, when calling "Hibernate.initialize(section.getListeElements())" I expect Hibernate is going to get appropriate settings in the hbm.xml files.

In fact, when navigating, Hibernate takes into account some settings, but not all. Hibernate is OK with batch-size setting, but does not take into account fetch="join" (see above). Both settings batch-size and fetch="join" seem to work well together.

It won't. Hibernate.initialize() is never "cascading". Calling "Hibernate.initialize(section.getListeElements())" will only retrieve the collection. It won't even « initialize the target entity objects that are referenced by this collection » (cf. page 590, in JPwH). To do it, you'll have to call Hibernate.initialize() recursively on evey proxies.


I guess these concepts are orthogonal, as we say :-). In fact, I was not clear enough. When I say that HQL overrides any settings in your mapping, I speak about the fetch plan. batch-size="B" is just an optimization that reduces the N+1 selects problem to N/B+1.