> I took a quick look and didn't see this topic being discussed previously
on
> this list or in the issue tracker. Please let me know if it's already
been
> hashed out.
> The handling of null in Linq is a bit of a thorny area, and it makes a big
> difference to get it right now since it would cause breaking changes in
the
> future. At the root of the problem is the fact that SQL uses ternary
logic
> (true, false, NULL), where C# only uses binary.
> The operators don't match up properly. As well, MS SQL Server doesn't
have
> an operator like the ANSI "IS NOT DISTINCT FROM"
> operator, making comparisons involving null long and poorly
> performing. There's an issue (NH-2370) that indicates the performance
> problems this causes. Linq to SQL handles null comparisons in a different
> way than NHibernate's current provider. I believe this is likely to cause
> not only some confusion, but problems with performance. Here is what MSDN
> has to say about the semantics of null in Linq to SQL:
Doesn't NHibernate treat null comparisons as the SQL equivalent?
Linq to Sql makes an attempt to mimic the differences between
VB.NET's null comparisons and C#'s which differ, however this isn't always
working because the outcome of a subquery for example is unknown (or an
aggregate returns null etc.)
FB
>
> ---
> Null semantics
>
> LINQ to SQL does not impose null comparison semantics on SQL.
> Comparison operators are syntactically translated to their SQL
equivalents.
> For this reason, the semantics reflect SQL semantics that are defined by
> server or connection settings. For example, two null values are considered
> unequal under default SQL Server settings, but you can change the settings
> to change the semantics. LINQ to SQL does not consider server settings
when
> it translates queries.
>
> A comparison with the literal null is translated to the appropriate SQL
> version (is null or is not null).
>
> The value of null in collation is defined by SQL Server. LINQ to SQL does
> not change the collation.
> ---
>
> From other articles on the net, people indicate that object.Equals() can
be
> used when you really want null to be considered in equality comparisons.
>
> My thought is that to work with SQL Sever in a performant way, and be
> consistent with Linq to SQL, the current null semantics should be changed
to
> match.
>
> As an extension to this, the way object.Equals() is translated to the
> database should be done through a dialect. That way, SQL Server can use
its
> complicated expression, but other databases can use IS [NOT] DISTINCT FROM
> and <=>.
>
> Patrick Earl
