Did anyone faced the following problem? If you left outer join fetch a collection from "the same" object with "different" where-clauses, the results of the "non-first" queries remain always similar to the the result of the "first" query. Can anyone confirm this behaviour? An Example:

from Alpha as alpha1 left outer join fetch alpha.betas betas1 where betas1.number = 0

from Alpha as alpha1 left outer join fetch alpha.betas betas1 where betas1.number = 1

Suppose we have one Alpha-object 1:n-connected with many Beta-objects, some with 0s and some more with 1s or vice versa. Nevertheless the fetched Beta-Sets to alpha remain the same after the second query. Seems like the session cache does not update collections fetched to one object within different queries. I´m using hibernate v3.1.2 and one session along one session factory (not closing after every query).
When I´m doing the same, but close the sessions after every query, than it works, but that makes no sense to me. I have no errors, its only this inefficient behaviour, what makes me thinking. Maybe it´s an hibernate architecture problem, maybe it´s a feature? Can anyone help?

If you expect that betas collection would have different elements depending on the where clause in the HQL then you have wrong expectations. That is the conceptual difference between ORM and SQL type of approaches.

With Hibernate those queries mean: please return Alpha objects where are betas with the following properties are present. The request returns whole Alpha objects which have collection of Beta objects with ALL kinds of properties because of definition of the Alpha object.

...yes, in both cases I want to load "the same" whole Alpha-object, but with different sized Beta-collections fetched because of different where conditions. But it does not work within one session. Fetched collections remain fetched in memory, they will not be updated there by a later query. Someone can give me a solution for this kind of problem?

[quote]If you expect that betas collection would have different elements depending on the where clause in the HQL then you have wrong expectations.[/quote]

This is wrong. Closing the session or clearing the session cache between the two mentioned queries results in different sized beta collections, so why does it not work in a normal way without wasting so much performance?

Hibernate documentation is vague in this regard and I guess it is not stabilized ideologically. For example at
http://www.hibernate.org/hib_docs/v3/re ... ryhql.html
we can read the following:
---
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. The only reason we might need an alias is if we are recursively join fetching a further collection
---
Right after the example:
---
from Cat as cat
left join cat.kittens as kitten
with kitten.bodyWeight > 10.0
---
I would insist that the query above should return Cat objects with all the kittens regardless of their weight as long as at least one kitten for the cat has body weight that exceeds 10.

Reason: it is Object Quesry Language, not SQL, and since we are getting Cat object those objects should have _all_ their properties fetched or proxied.

So what would be the right way to efficiently fetch all associated object matching certain criteria?

...and actually this statement:
is wrong for the following query:

--
from Cat as cat
left join cat.kittens as kitten
WHERE kitten.bodyWeight > 10.0
--

We will get all cats that have kittens with kitten.bodyWeight > 10.0 and cat.kittens set will be loaded ONLY with kittens matching the criteria. The problem is that without clearing session cache it is impossible to do the following query:

--
from Cat as cat
left join cat.kittens as kitten
WHERE kitten.bodyWeight > 20.0
--

Andrei