> I didn't make much progress on the improved version and now I'm short
> on time again. Did have an interesting question though... do you
> suppose the join detector for select and order by should be using the
> same member depth check that the where join detector is using?
Mhm. In the where part, there's no need to join a.B even if B points to an
entity if we only ask
a.B == null
So a.B does not get a join (even if it gets a "potential mapping" if it joined
somewhere else).
What does a.B mean in the select part? Doesn't it mean "do join/load the
object"? Or do you need an additional "eager" tag?
What does a.B mean in the order part (according to HQL semantics)??? If it is
not allowed, then the check is irrelevant; if it orders on the joined PK, then
the member check is necessary (or useful).
[BTW, my statement "there's no need to join a.B ... for a.B == null" is
actually wrong: If the association B is marked with <...not found="ignore" ...>
- see section 5.1.10 in documentation, then just having a non-null value in B's
column is *not* sufficient to conclude that a.B == null. But isn't this an HQL
problem/feature/effect??].
> I'm tempted to use the Select detector for Where clauses too until we
> can sort out how to implement the inner join optimization better. At
> least the results will be "correct" in all cases AFAIK.
Yes, I agree.
Other possibility (as I did not look into the Select detector - does it
reliably find all member expressions htat must be joined?): Comment out that
line in WhereDetector.Find that calls MakeInner... Disadvantage: All the
incomplete mapping machinery runs completely uselessly.
Harald M.
--
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
