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
>>
>
