Patrick, all,
I have now attached a completely new implementation of "pure outer join
semantics" ("(||-4) semantics" in my original document) to NH-2583; and I also
included a document "JoinOptimizationForPureOuterJoinSemantics.txt" that
explains why and how outer joins are replaced with inner joins.
... and yes, the code is simpler than with (||-5) semantics. Still, I think one
has to read my text to understand it ...
Please enjoy / review / discuss / include in NHibernater etc.!
Best regards
Harald M.
-------- Original-Nachricht --------
> Datum: Wed, 6 Apr 2011 12:44:42 -0600
> Von: Patrick Earl <[email protected]>
> An: [email protected]
> Betreff: Re: [nhibernate-development] NH-2583 - Query with || operator and
> navigations (many-to-one) creates wrong joins
> I'll see it on the weekend, but I had a question if the code basically
> defaults to outer join. In other words, if we're not 100% sure if we
> can optimize to an inner join, does it do an outer?
>
> Patrick Earl
>
> On Wed, Apr 6, 2011 at 10:12 AM, Patrick Earl <[email protected]> wrote:
> > Thanks again Harald!
> >
> > I'm busy for a couple days, but I'll look at it as soon as I can. At
> > the very least, I'll be able to look at it on the weekend again.
> >
> > I did notice what you said about the test cases and I was curious what
> > you would do about the cases where there's no direct equivalent in
> > Linq to Objects.
> >
> > Patrick Earl
> >
> > On Tue, Apr 5, 2011 at 3:27 PM, Harald Mueller <[email protected]>
> wrote:
> >> Hi Patrick, all,
> >>
> >> here is a version of the "pure outer join semantics" with inner join
> optimization.
> >> Some remarks:
> >>
> >> * I am not at all certain the "inner join intelligence" is correct. I'm
> very inclined to write a formal proof of the algorithm ... So I post this
> only to give an idea of the complexity of the code (it might increase a
> little, as right now I only check for a few special expression structures; it
> might also shrink, as one can see quite a lot of "structural code
> duplication" - however, I did not see an obvious way to reduce the code size).
> >>
> >> * I had to change the test automation (that was also one of my
> "psychological roadblocks" which took me a day to overcome): I'm quite sure
> that it
> is not possible to write Linq2Objects queries that are exactly equivalent
> to the "outer join semantics" also in exceptional cases. Therefore, my
> original testing strategy did no longer work. I therefore restricted the
> testing only to those cases where the query interpreted by Linq2Objects does
> not
> throw an exception; in such cases, the results must be identical [this is
> not true for == with nulls on both sides, as Patrick explained in his last
> email; there is no test case currently that uses this deviating semantics].
> >> One might argue that this is the right way to test a Linq SQL provider
> anyway - the results for "exceptional cases" should be open to a simple
> *implementation*, as Patrick more or less requested (and not a simple
> *semantics*, as I put forward).
> >>
> >> * The 342 NHib.Linq test cases are green. 74 of the 75 new test cases
> are also green; the "projection anomaly test case" has now of course been
> "ignored", as the outer join semantics does have this anomaly.
> >>
> >> * In our discussion, the ! operator (for Patrick) and equivalence
> rewriting of queries (for me) were, as I see it, an important topic. I hope to
> add a number of test cases (at least around 20) that show the behavior in
> such cases.
> >>
> >> I hope this code gives you a base to decide whether to proceed along
> this way.
> >>
> >> Regards
> >> Harald
> >>
> >>
> >> --
> >> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
> >> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
> >>
> >
--
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
