Hibernate 3.1.3
Oracle 10g
Hi,
I make this thread because the informations I have are not enough up to date for some, and can't be sure for some others, so I prefer to get a more "official" one.
We use massively lazy loading.
Take the example of an object "Entity".
We have a lot of collections inside, but I dont care, just consider one of them, called support desk, many to many relation, mapping as follows.
Code:
/**
* @return Returns the supportDesks.
* @hibernate.set name="supportDesks" cascade="all"
* table="AM_ENTITY_SUPPORT_DESK"
* @hibernate.collection-key column="CX_ENTITY_OID" foreign-key="FK1_AM_ENTITY_SUPPORT_DESK"
* @hibernate.collection-many-to-many class="com.name.package.hidden.model.SupportDesk"
* column="AM_SUPPORT_DESK_OID"
* foreign-key="FK2_AM_ENTITY_SUPPORT_DESK"
*/
I'm putting myself in the case where I want to load Entities with the set of Support desk initialized.
My HQL string looks like that.
Code:
private static final String HQL_GET_ENTITY_FETCH_SD = "from Entity e " +
"left join fetch e.supportDesks " +
"where e.name = ?";
It is just a dummy test. Don't look too much into it.
Currently experienced:
I have 3 entities named 'A' in my DB.
The first has 2 Support desk.
The second has 2 Support desk.
The third has none.
Result of the select query with parameter 'A' -> 5 Entity objects.
It is a
normal behavior, of course.
The SQL query actually returns 5 rows. And so Hibernate returns 5 objects.
I found some things related to that in Hibernate in Action 2005 (dont have more recent).
Hibernate in Action 2005 wrote:
We disabled batch fetching and eager fetching at the mapping level; the collection is lazy by default. Instead, we enable eager fetching for this query alone by calling setFetchMode(). As discussed earlier in this chapter, this is equivalent to a fetch join in the from clause of an HQL query.
The previous code example has one extra complication: The result list returned by the Hibernate criteria query isn’t guaranteed to be distinct. In the case of a query that fetches a collection by outer join, it will contain duplicate items. It’s the application’s responsibility to make the results distinct if that is required. We implement
this by adding the results to a HashSet and then iterating the set.
I think the sentence in bold is wrong. Or maybe things changed from that time. Or maybe misphrased..
Because in my example I dont actually need the outer join to experience duplicate items. Of course in the given example, if i remove the outer joins, I will get only 4 rows returned, and not 5.. But if I talk from model-side, 2 objects from the 4 are really duplicates.
Enough talking... What is happening seems quite clear for me (of course correct me if I'm wrong)... So the question now:
I dont like at all the idea of throwing away duplicate entries using the Hashset like a filter.....
Is there any new possibility to handle that kind of behavior ?
Thanks
Login
FAQ
Search
