See, I think you should always go the linq to objects route. Linq is an abstraction that sits on top of something (objects, sql, whatever), so it's the abstractions job to translate the intent. You should be writing (a.b != null) && (a.b.c == x) because you don't know what you are applying it against. What should happen is the abstraction should reduce the intent down to what it's target is expecting. Even though you have those expressions there doesn't mean that you need to send "a.b IS NOT NULL AND a.b.c = z.x" if you can just write a.b.c = z.x.
At the same time, if you can't predict the intent absolutely, then you are going to have to fall back to sending the full intent. I think if we were just writing out sql from the linq expression, this would be simpler. Since this is making an hql statement, maybe it's even simpler, maybe much harder. The question is: who should be reducing the expression? The linq provider or the provider that takes hql and emits sql or both? Either way, somewhere the expression should be reduced because SQL doesn't need the null check when the null check was already done by a join (not necessarily the null check between two values)
