Hi all,
I have an object model where a workorder has a set of replicates. Each replicate has a set of reactions. Using 2.1.1 and outer join=true, max_fetch_depth 3, when I load a workorder up by it's primary key, it then lazy loads the replicates in one query.

However, since I always need the reactions for the each replicate, I want it to outerjoin and load them. However, instead it issues single select statements for each set of reactions per replicate.

Should Hibernate be able to outerjoin across collections and load the tree up like that? Or does outer-join over multiple objects only work with non collections?

Eric

In the docs it says:
3.5.2. Outer Join Fetching
<snip/>
By default, the fetched graph ends at leaf objects, collections, objects with proxies, or where circularities occur. <snip/>

What I am guessing is that since I have a collection, each of whose children should load another collection, the outer join fails because the collection can't load another collection, based on the fetch graph ends at collections..

Does that make sense? If I wanted to write my own logic to do this collection loads another collection like this: select * from replicate left outer join reaction on replicate.replicate_id=reaction.replicate_id where replicate.workorder_id=126
then would I still be able to do that in the Hibernate architecture?

There is an outer-join attribute of <set>, <bag>, etc.

One more attempt to get it to work.. I am able to do a collection of collections query if I use this HQL:
"from Replicate as rep left join fetch rep.reactions where rep.workorder.id=126"

However it doubles the number of rows returned as I have 2 reactions for each replicate. In the docs it suggests this won't happen:

Here is the section from 10.3 in the 2.1.1 docs...
from eg.Cat as cat
inner join fetch cat.mate
left join fetch cat.kittens
A fetch join does not usually need to assign an alias, because the associated objects should not be used in the where clause (or any other clause). Also, the associated objects are not returned directly in the query results. Instead, they may be accessed via the parent object.

In my case, the associated objects seem to be returned directly...

You have misunderstood the doc. This behavior is expected and correct.

Last post hopefully! I was able, via kinda ugly code, to get this to work:

List list =
ServiceLocator.currentSession().find(
"from Replicate as rep left join fetch rep.reactions where rep.workorder.id=126");
assertEquals(286, replicates.size());
for (Iterator i = list.iterator(); i.hasNext();)
{
//Object[] tuple = (Object[])i.next();
//Replicate rep = (Replicate)tuple[0];
Replicate rep = (Replicate) i.next();
assertEquals(2, rep.getReactions().size());
if (!replicates.contains(rep))
{
replicates.add(rep);

}
}

assertEquals(143, replicates.size());

is my unit test... Basically, while I do get double the number of rows I expect, I can then iterate through and find the unique ones.. This all works with just 1 database query, versus the 143 odd queires before. Additionally, it seems there should be some sort of uniquelist object I could use to do the unique part for me..

I would personally use:



since it is much simpler. If you need tio preserve ordering, use a LinkedHashSet.