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