Steve Ebersole closed HHH-2073.
<quote>This is not reflected by a foreign key constraint in the database (hence it
allows child to have no parent)</quote>
This is true simply because of the bad design choices of your db. Had the db been
designed properly and used nulls to represent a non-existent relation, then an FK could
very well have been defined to cover/protect this association.
The only "work around" I am aware of is to design the database properly. As
much as you or the original designer wants to think otherwise, a non-null value is not a
The only way to not have the second query issued (aside from fixing the db design) is to
add as new feature to explicitly deal with that scenario. Not saying I am necessarily
against that idea, just saying that adding code to work around bad db design decisions is
not high on our priority list. If you want to take a stab at implementing such an
enhancement and the work is good, I would certainly consider accepting such a patch.
many-to-one join fetch with optional parent causing stray query to
Issue Type: Bug
Reporter: Adam Hardy
I have a call centre application which uses a mature database and is therefore pushing
Hibernate to accomplish the mappings I need. The issue here is extra queries that
Hibernate is firing where I set up the mapping to do a join in one hit.
I am fetching child objects which may or may not have a parent. The child's foreign
key points to a non-primary key on the parent. This is not reflected by a foreign key
constraint in the database (hence it allows child to have no parent).
If the child object has the foreign key 0 instead of null, which is the protocol in this
database, then the parent which doesn't exist is not (& cannot) be instantiated,
no problem, but then after processing the resultset, Hibernate fires off another query to
fetch the parent that it could not find data for in the first query.
This is obviously unnecessary in this context and degrades the performance on large
searches on this child.
I have classified it as minor since I suspect there may be work-arounds but I have not
researched that yet.
I didn't know whether I could put the mapping XML in the query, so I have attached a
simplistic testcase example that demonstrates the problem.
The following forum messages are relevant and the latter contains the mappings, which is
easier than extracting them out of the testcase zip:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see: http://www.atlassian.com/software/jira