Hi -
>
> Does this take care of the "default to outer join" thing that was
> briefly discussed earlier?
Yes: The code first creates outer joins - for joins necessary for the Where as
well as the Select and OrderBy parts. Additionally, it keeps that "mapping
information" explained in the text that helps to find out which joins can be
made inner. On exactly these joins, MakeInner[IfJoined] is called at the end of
WhereJoinDetector.Find. As a test, one could just comment out this loop -
everything must still work.
>
> Also, did you happen to figure out a way to verify the cases where
> linq2objects would throw an exception but the outer join returns more
> values?
I just dont test these objects - they are not created in the tests. So the
tests right now *only* check the equivalence of Linq2Objects and NHib.Linq for
sets of objects where the condition does not throw an exception when evaluated
against an object in Linq2Objects.
Actually, I do not see any other possibility for that "extended part of
NHib.Linq" semantics that has no counterpart in Linq2Objects. With (||-5)
semantics, there was a defined rewriting from NHib.Linq expressions to
Linq2Objects expressions also for such cases (the "formal introduction of
existence guards"). But with (||-4) semantics ("pure outer join semantics"),
such a rewriting algorithm in itself seems like a research project in formal
logic to me ... and even if there is such a rewriting, I doubt whether one
would call the comparison a "test", as the correlation of the NHib.Linq
expression and the "corresponding" Linq2Objects rewrite would probably not at
all be obvious and hence not convincing ...
Actually, my stance is:
* I would still prefer the (||-5) semantics, because it is *simply explainable
on the Linq level* - so there is a "simply explainable comparison behavior" on
which we could base a verdict whether a certain NHib.Linq behavior is "right"
or "wrong".
* But if we use (||-4) semantics ("pure outer join semantics"), I am only
interested in expressions that do not throw exceptions in Linq2Objects, as
there is (right now) *no* "simply explainable" comparison (!) behavior on which
to base a "right" or "wrong". In other words, if my programmers came to me and
would complain about a "wrong behavior" of NHib.Linq, I would tell them to
rewrite the query such that Linq2Objects does *not* throw an exception
(tpyically by adding manual existence guards) and *then* check whether the
result is different or not. Therefore, I don't see a reason to test widely for
such cases.
(However, you can certainly write a few manual tests that pin down your
expected behavior in such areas. A few of my manual tests already should do
this ...).
Harald
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone
