Since there's not a lot of activity around this topic at the moment,
here's a summary of the results so far:
Code Votes:
A+C = Linq to SQL v4
A+C = Entity Framework v4
A+D = llblgen
A = Critieria
A = Hql
A+D = QueryOver
A+D = Old NHibernate.Linq
B+D = New NHibernate.Linq
Individual Votes:
A
A
A+D
It seems that A is a clear winner, with nothing other than the current
code using the B technique.
Regarding the C+D debate, it seems to be an "Everybody vs Microsoft"
thing. Given that "Everybody" includes many decisions from our
existing community, I would argue that D is the selected choice.
Unless anyone has further information to add, I will file a bug report
regarding the behavior of A vs B, and have warm fuzzy feelings about
the current implementation using strategy D.
Patrick Earl
On Fri, Oct 29, 2010 at 10:22 PM, Patrick Earl <[email protected]> wrote:
> Here is more information about the C and D options.
>
> Option C acts as if the variable in the LINQ query is just like any
> other database element. It generates A = B except for these special
> cases:
> X == null (literal only)
> X != null (literal only)
>
> With option C, LINQ statements that look like this:
> .Where(customer => Customer.Representative == representative)
> generate this in all cases:
> Representative = @representative
>
> Option D assume that the developer is aware of the value of the
> variable and uses the variable contents to figure out whether to
> generate an IS NULL clause. It generates A = B except in these
> special cases:
> X == null
> X != null
> X == nullVariable
> X != nullVariable
>
> Using:
> .Where(customer => Customer.Representative == representative)
> generate these depending on if representative is null:
> Representative IS NULL
> Representative = @representative
>
> In support of option C:
> -Consistent with Linq to SQL
> -Consistent with Entity Framework
> -Same result as if variable was an actual SQL variable.
> -Might be difficult to see that an expression like c => a.X == b.Y is
> going to be converted to a.X IS NULL just because b.Y is an in-memory
> variable that is null.
>
> In support of option D:
> -NHibernate already does it this way.
> -Developers seem to expect it. 3/3 of polled developers at my office
> expected it (one very strongly so).
> -The connect bug report expected it and gave many other examples of
> people expecting it.
> -If X == null is already special cased, it's a logical extension to
> special case X == nullVariable.
> -It is strange if X == Y is not the same as X == null when Y == null.
> -Rarely does anyone actually need "= null" to evaluate to NULL. When
> it does come up, it's usually desirable to have it converted to IS
> NULL.
> -llblgen's LINQ provider does it this way.
>
> So, from the perspective of a programmer who's going to use the
> system, I now prefer option D.
>
> So my final vote is for A+D (change the equality part to convert == to
> = directly, but leave the null variable handling alone).
>
>
> I realized that it was silly to use "A,B,C,D" when it's really two
> decisions. Sorry if that confused anyone. The options at this point
> are:
> A+C
> A+D
> B+C
> B+D
>
> Looking forward to hearing more people's views on this issue.
>
> Patrick Earl
>
