I'm having a pretty serious fetch joining problem. I've went back to an older application that I wrote a long time ago. It's not a mess, but my Hibernate skills were not nearly as competent as they are now. Anyhow, fetch joining with collections doesn't seem to work correctly on this project as it does on others, and I'm having trouble figuring out what could be the problem :/

Basically Hibernate is returning duplicates of the object I'm selecting for each element that it fetch joins. So if I have object X with 3 Y as children, the query will return a list of 3 X's. This is not what I would expect since I have done left join fetch on many queries on other projects.

I guess my question is how can this happen? I'm upgraded the hibernate2.jar to the latest version and I'm using the same database (postgres 7.5) as the other projects where fetch joining is working just fine. Here is a simple example:



As you can this, query is simple. If I take off lazy loading for page.children and remove the left join fetch, the query will return 47 results in my case (correct number). However, if I run this query with lazy-load="true" and put back in the left join fetch, the query returns 80 results, so 33 are duplicates. As an example, I did a system out for each Page in the list returned by this query, printing page.name and it's number of children. The objects with the same name also have the same Id. Here is what happens:



So as you can see, the children are being mapped by hibernate just fine. This is quite frankly baffling me. Anyway, here is the mapping. I've removed a lot of properties and other sets to make this beast easier to read. I assure you that even if I take out the other mappings just to get it to work, the problem still happens.



Anyway, I'd appreciate any advice. THe only thing that I can think up right now is that since the children are the same type as the parent, perhaps Hibernate isn't handling it properly.

This is normal, Hibernate does not make the results unique. You will have to do that yourself (drop them all in a HashSet for example)

Are you sure? I've done fetch joining like this, with backed test cases, and I've never had this problem. To me, fetch joining behaved exactly as doing lazy-loading or not making the collections lazy at all.

I did wrap the list in a HashSet and it removed the duplicates, but I don't understand why this has to be done. Isn't this a big waste of memory in building 33 objects with unique children set references? I guess 33 objects isn't a lot, but I'm detecting a scalability problem unless it's handled very efficiantly inside Hibernate. Even still, clients to the code I'm modifying expect a List, not Set and this will cause some problems unless I convert the Set back into a list. Sigh..

Are you sure I can't just tell Hibernate to do this for me with the hope that it can do a better job at optimizing it than I can?

Um. It is not 33 objects, it is 33 references to the same object. Basically, there is no reason why Hibernate can do this unique-ification any more efficiently than you can do it.

I realize it's references, but the children are still sets of references (which may be the same ones or different ones, but as a Hibernate user, I don't know how it does that).

Regardless, the only way I can quickly fix this problem is by wrapping the query.list() in a HashSet, then re-wrapping it in an ArrayList (to avoid changing the interface since many clients will break).

I guess this just hasn't come up for me, ever. That's strange because I really have been doing fetch joins a lot and have not even noticed this (and I make the effort so that my test data in dbunit is quite realistic).

So there is no way for Hibernate to just drop the duplicates outside of what I'm doing?