Tapio Kulmala <[EMAIL PROTECTED]> writes: > You said that foo = null is always false
Yes, he said that, but he didn't mean it. :) This whole thread is another example of why it's a big design fault to ever include NULL into SQL. Three valued logic is just not for everyone. As the cited link said: The ANSI SQL behaviour is to evaluate *every* comparison including a NULL value to UNKNOWN! SQL is not a boolean logic, it is a three valued logic! So a comparison like a.foo = b.bar where both foo and bar (or only one of them) have a value of NULL yields UNKNOWN. What is done further with UNKONWN depends on its occurance. In a WHERE clause, UNKNOWN is further evaluated to FALSE. So in a WHERE clause any comparison containing a NULL value eventually evaluates to FALSE. The value NULL has to special cased always. What Ayende tried to say is: NHibernate is independent of the logic implemented in the RDBMS. If you have SQL Server with ansi_null off, fine. SQL Server will evaluate a different logic than ANSI SQL, thus resulting in different resultsets, but NHibernate isn't interested in the logic of the RDBMS, it just handles the result set -- completly independent of the logic of the backend. So if you are lucky with the results yielded by ansi_null off, just fine, NHibernate can handle that. As a word of warning: Your code may be harder to understand when relying on ansi_null off for other developers (used to ANSI SQL logic). That's about the only problem. -- Until the next mail..., Stefan.
pgpomYVXLxU6j.pgp
Description: PGP signature
