On Fri, Oct 29, 2010 at 2:23 AM, Frans Bouma <[email protected]> wrote:
>> Option A: Simple equality. Follows SQL, Linq to SQL, and EF, but is
>> sometimes confusing.
>> Option B: C#-style equality with long expression. Rules are clear but
>> generated SQL is sometimes poor.
>
> B is actually what Linq to sql does, hence the problems they had in
> the connect issue.
I assume you're talking about the handling of Equals()? Linq to SQL
passes == straight to the database as = in all the simple queries I
tested. NHibernate isn't doing that currently, hence this discussion.
Does VB use Equals() as its default equality operator? Maybe that's
where the discrepancy is coming from in this discussion.
Ignoring the special handling of Equals(), it sounds like you prefer
the A+D route.
The connect issue is specifically about == nullVariable and MS went
the DB way... == is always = (except in the exact literal == null and
!= null cases). It seems like the problem is that MS went so far into
making it consistent with the DB that they are surprising users. MS
made it so that if you type == somethingNull, it generates =
somethingNull in the DB, which doesn't match anything.
I'm waffling on the whole C / D decision, but I'm still clear on the A part.
Patrick Earl
