Wednesday May 25th

Tuesday May 24th

NHibernate.Linq Pitfalls: Casting

One thing that needs to be always remembered when writing NHibernate.Linq queries is that it is going to be translated into SQL eventually. What this means is that we can't do everything in our Select or Where conditions - we are restricted by the capabilities of underlying database and SQL language itself.


This is one of those spots where I feel Linq isn't as good as other solutions I've seen. In Sybase's PowerBuilder product, you can pass an array directly to a SQL IN statement and it will automatically populate the IN statement. It would be much cleaner if Linq could do something similar here.

You can do that in NHibernate.Linq too - my second query does that. But you need to ensure that the types are converted correctly and at C#-side.

Using NHProfiler for things debugging your NH code makes things like this a little easier to find. Everyone gets to learn these gems of the art of NHibernate through experiencing the pain first-hand. It's nice to see example articles like this pop up to explain those ins and outs.

This is an important pitfall to point out, so well done for that.

However, I believe I'm right in saying that an even easier way, and certainly more efficient (it doesn't require the conversion to a list and the corresponding allocation of memory) is to call `.AsEnumerable()` on the enumerable *after* the local operations but *before* the SQL operations.

Commenting on Stories is limited for now and will open up to those recommended by the community. Learn how
Loading DotNetKicks...
brought to you by the Kicks Network