[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6783?page=c... ] Greg Burcher commented on HHH-6783: ----------------------------------- Ok, I read the FAQ article, but I still think this is a bug. I fully understand the relational model, JOINs, SQL, etc. but one of the reasons that we use hibernate is to provide developers with an entity-based (not table-based) abstraction for managing persistent entities. I can't imagine a use case where the current behavior would be desired. This behavior needs to fit the interface contract provided by the Session/Criteria classes. The SQL-based implementation provided by hibernate should be invisible to the caller. If I use a Criteria-based query to request all persistent objects of a certain class, I do not expect to find duplicates in the returned list, regardless of how I have chosen to map the associations and/or fields of that class. This feels like a violation of the general Session contract of in-memory identity of persistent objects. I'm sure the references all resolve to the same in-memory contract, but returning multiple references to the same persistent object in one query feels like a violation of identity. I have not yet tested, but what happens if I call Session.get() with the identity value for one of these objects? Do you throw some sort of exception because there are multiple elements in the ElementCollection, causing multiple rows to be returned in the OUTER JOIN SQL query? Probably not. My guess is you manage to resolve the multiple elements in the collection and return the single persistent entity. Why would you not do the same thing in the Criteria.list() method? Do you return the single entity on Criteria.uniqueResult() or throw an exception? I don't understand why hibernate would not resolve the fact that there are multiple elements in the ElementCollection and return the single object, in the same way, for Session.get(), Criteria.uniqueResult(), and Criteria.list()? I suppose we can find a way to work around this, but I'm trying to understand how this is considered correct behavior? And in what use case the caller would want this behavior? Thanks, Greg -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6783?page=c... ] Wojciech Biela edited comment on HHH-6783 at 11/2/11 6:28 PM: -------------------------------------------------------------- I also found the same problem, and have spent a few hours figuring it out. With lazy fetching works one way, with eager the other, the argument that it is by design and not a bug would stand if it would behave the same way in both cases. Anyway why does a user of the API have to care about what kind of join is done there under. If I save 3 entities, I want to fetch 3, not 5. A workaround for me was to use {{setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY)}} on the criteria object. was (Author: ilfrin): I also found the same problem, and have spent a few hours figuring it out. With lazy fetching works one way, with eager the other, the argument that it is by design and not a bug would stand if it would behave the same way in both cases. Anyway why does a user of the API have to care about what kind of join is done there under. If I save 3 entities, I want to fetch 3, not 5. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira