C # weird lambda behavior

Question

Can anyone point out why this might happen:

I use NHibernate and Linq for this provider.

The code is not specified here:

 var sequence = session.Query<T>(); var wtfSequence = sequence.Where(x => true); var okaySequence = sequence.Where(x => x.Id > 0); 

Debugging shows that the sequence (which is an IQueryable<T> ) after that contains 2 elements that have been added to the database.

I expect the first Where statement to return all elements from this sequence, but unfortunately it leaves 0 elements.

(why???)

The second Where statement, in contrast, actually gives 2 elements, since it should work.

The following are NHibernate -> Sqlite for the first and second Where statements.

 NHibernate: select cast(count(*) as INTEGER) as col_0_0_ from "BinaryUnitProxy_IndicatorUnitDescriptor" binaryunit0_ where @p0='true';@p0 = 'True' [Type: String (0)] NHibernate: select cast(count(*) as INTEGER) as col_0_0_ from "BinaryUnitProxy_IndicatorUnitDescriptor" binaryunit0_ where binaryunit0_.Id>@p0;@p0 = 0 [Type: Int32 (0)] 

---

Now, if I test the same code with my InMemoryRepository , which stores each object in a simple list, (x => true) works fine with absoluteness.

So - why does this happen when using NHibernate ? Is this a mistake, or am I doing something wrong?

Thanks.

Answer 1

I do not know NHibernate, but the problem is obvious from the generated SQL: your database does not consider true (lowercase t) equal to True (uppercase T). In the SQL server, you can change this by changing the database setting (this is a really bad idea if you do not want case insensitivity for other reasons).

My guess is the NHibernate bug that needs to be circumvented. Test t => 1 == 1 instead of t => true , which may work depending on how NHibernate code is written.

Answer 2

I assume this is an error in NHibernate based on the SqLite output you are showing. You can try X => X.Id == X.Id and not X => true and see if this works.

Answer 3

Looks like a mistake. Its conversion of a boolean operation to a string evaluation, and even this is screwed up, because it sets the query with true and evaluates with true , so the case-sensitive test will fail.