Has the original question of this post been answered? Did it have to do with the property-ref relationship?
3.2.6ga
I believe I am seeing the same issue. In my case, I have a query that looks something like this (I've tried to simplify these so they can be more readable):
Code:
Criteria criteria = getCriteria(ClassA.class)
.setFetchMode("subOfB", FetchMode.JOIN)
where
subOfB is of class SubOfB
which is subclass of class SuperB
SubOfSubOfB is a subclass of SubOfB, and the type of the actual JOINED instances returned in the query above.
The B heirarchy is mapped with table-by-subclass strategy.
ClassA has a @OneToOne mapping to SubOfB, e.g. a part of SubOfB would look something like this:
Code:
@OneToOne(fetch = FetchType.LAZY, mappedBy = "subOfB")
protected ClassA classA;
The ClassA side looks something like this....
Code:
@OneToOne(fetch = FetchType.LAZY)
@JoinColumn
@ForeignKey(name = "FK_CLASSA_SUBOFB")
private SubOfB subOfB;
I'm running into the same issue as the email that started this thread. That is, when I call
Code:
Hibernate.initialize(criteria.list());
A single query with all the appropriate joins get created. Something like (along with a 2nd query)...
Code:
select * from ClassA, SubOfB, SuperB, SubOfSubOfB where (proper left join statements starting with ClassA)
select * from ClassA where subOfB_id=?
The 2nd query is run as many times as there are rows returned in the 1st query... even though all the contents appear redundant, since it's just a subset of data returned in the 1st query.
( By the way, if you change the fetch clauses above to FetchType.EAGER in the @OneToOne mappings above it makes no difference. Notice Criteria overrides fetch type. The fetch strategy hint does appear to work, since the 1st query is generated with all the necessary joins. Also, I made sure to set max_fetch_depth sufficiently high for testing purposes.)
With in B class heirarchy, primary keys appear to be mapped correctly. The resulting 1st query properly left joins on the subject, ClassA. So I'm confused as to why Hibernate would need to rerun queries for ClassA again based on subOfB_ids.