Hoping someone can help me with a 3.2.6.GA problem.

I have an entity E with a one-to-many relationship to its sub-entity X; E has a list of Xs.

I persist an E with 2 Xs in its list, X1 and X2.

I use Criteria to .scroll() the results of my query. The criteria has no restrictions, it's just a select *.

I get back 2 results. The first is an E with X1 in its list, and the second is exactly the same thing. In fact, the two results are the same exact object in memory - that is, their identity hash codes are equal!

So I have 2 questions:
1. Is it a bug that I never get X2 back? Is this fixed in later versions?
2. How can I configure hibernate to return a single result instead of two? That is, I'd prefer getting back E with both X1 and X2 in its list.

Thanks,
Brian

medotin,

You should not use scroll() for traversing object graphs with parent-child relationships, because that API relies on the number of lines returned by your resultset, and there will be normally many SQL selects executed in order to retrieve a parent-child relationship.

You should return the parents only, and then traverse them internally with your Java code.

Alternatively, if you absolutely have to return parents alongside with children, obtain your resultset as your normally do, but apply a Transformation.DISTINCT_ROOT_ENTITY to them.
That will get rid of duplicates on the parent side.

Thanks for the reply Gonzalo. If you wouldn't mind, I'd appreciate hearing how you would approach my situation because I still can't see a solution given your suggestions.

I'm using scroll for two reasons, first because the query will return millions of entities that will not fit into memory, and second because I need to commit and start a new transaction every once and a while so as not to overflow my DB's transaction log. Scroll gives me a way to do both.

So, you suggest 2 ways of dealing with using scroll.

First is using Transformation.DISTINCT_ROOT_ENTITY. I think this doesn't work; it will return 1 result as desired, but still would only have X1 in the child list. I think also it wouldn't work because I .clear() the session after each .next() on the ScrollableResults (was having OOM errors from the persistence context holding on to all the entities) so the duplicates would not be found.

Your second suggestion is to traverse the parents in Java code; what do you mean by this? Are you suggesting that I use Transformation.DISTINCT_ROOT_ENTITY and for each result returned I completely reload it using its id so as to obtain all the children? This seems like it would work (except, potentially, because I .clear() the session as previously stated) but would kill performance.

Thanks,
Brian

Yes,I am suggesting exactly that. At least, the parents will provide you some breakdown in the number of children.
Remember to use a lazy parent-child association.
If the number of children depending on each individual parent is acceptable, then use a fetch="join" mapping.
Otherwise use fetch="selct/subselect", or set a batch size=20, or even write a new query and use scroll() with it.

The only bit I've left to understand is why X2 isn't being returned in my use case. When stepping through the code I see the object representing X2 being instantiated, but it is never handed back to the user. This seems like a bug.

If it was lazily mapped, it will only be really instantiated once a method of it is called. Until then, you only have stub.

In my case it's eagerly mapped.