Good choice (A+D). I never understood why MS went the C route, it makes no
sense from a DB point of view.
FB
> 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
> >
