Outer, Inner. I am confused so the only way you would get "Outer" results is if the details has orphan records and they are comming into the resultSet. Or a cartisan product. By default join queries in any SQL Hibernate or any other is an inner join.
I don't understand why you are saying you are getting an inner join.
I can guarantee you that there are no orphaned records...yet Hibernate is still generating outer joins instead of inner joins...
What do you mean "by default"? Outer joins are quite common, I'd just like to be able to choose when to use them, even if there *were* orphaned records.
Here are my two classes:
Here are the corresponding *.hbm.xml files:
The tables are simple and match the config files...there are no orphaned records in the an_announcement table...they all have a category ID associated w/ them.
Here is the SQL generated by Hibernate (formatted for readability):
Soooooooo? Any ideas? I have "Hibernate in Action" and I see examples of where SQL inner join syntax is used in HQL...but like I said, I'm using Criteria "queries" instead...and would prefer not to use HQL.
Well, maybe, and I say maybe because I am not sure, but maybe it is because of the one-to-many mapping in the Parent tbale, and not a many-to-one in the child.
That might be the reason why the query is an outer join.
Joined: Apr 26, 2004
It does it w/ a many-to-one defined in the child as well. The only reason this example does not have that is because I don't have a getter/setter defined for the parent in the child object....so it doesn't make any sense to populate a field that isn't there (in the child.)
I did some reading through the join association chapter of Hibernate in Action last night (still working my way through the book.) and apparently lazy joins are always going to be outer joins. Otherwise, your option is to use eager fetching which has obvious performance problems should you accidentally load the entire database into memory at one time. I could have said fetch="select" instead of "join" but then it would generate separate select statements for each of the child objects in the list...which is a good example of the "n+1" selects problem...this will perform poorly w/ many objects since you'd be executing many statements vs. one statement.
I'm still working on this...I'll report my progress.