One-to-one two sided relationship causing two outer joins.

Question

We have a fairly simple one-to-one relationship between two objects A and
B. A maps to table A, B maps to table B. A holds a foreign key to B. Both
classes hold a reference to each other.
What we are trying to achieve is to load both A and B with a single
intelligent SQL query. The only thing we can achieve is either two queries
or one query with two outer joins.
When both A and B have the other in the default fetch group and
EagerFetchMode set to join, Kodo dispatches is something like this:
SELECT whatever FROM A t0 LEFT OUTER JOIN B t1 ON t0.B_ID = t1.ID LEFT
OUTER JOIN A t2 ON t1.ID = t2.B_ID
The obvious problem with this is that is is going to be very innefficient.
Isn't the second join needed?
If the eager fetch mode is kept the same but A is removed from the default
fetch group of B then we get two queries. The first one is a left outer
join between A and B and loads all the columns from both A and B. (At this
point in a debugger, A holds a reference to B, but B's reference to A is
null). The second query fetchs all columns from B. But still the reference
to A is null. It's only when we actually navigate to A from a B that the
reference is populated. (Luckily no query is executed at this point).
Is there anyway to achieve the loading of both objects with a single SQL
query dispatched by Kodo?

Answer 1

You should be able to get what you want by querying for the B instance with A in
its default fetch group (but keeping B out of A's default fetch group). It
shoudl result in one query with a single outer join, and no additional queries
when you traverse the A.B relation.
The reason for the two joins/queries in other scenarios is that Kodo treats each
direction of the relation as a separate relation that has to be fetched on its
own. The reason the above solution should work is that when the A record is
read, the foreign key values for the B record are cached. When you traverse the
A.B relation after both A and B are loaded, Kodo matches these cached foreign
key values to the B instance in the PM cache and doesn't require a DB trip.