Agreed, the join should be outer (i.e., shouldn't filter out null values). One consideration though; presumably the reason we like it not to filter is because it behaves the same way as the in-memory LINQ provider (Queryable<T>). However wouldn't each of these examples generate a null reference exception? (Should the LINQ provider do the same?)
From: Steve Strong Sent: Thursday, July 08, 2010 10:24 AM To: nhibernate-development@googlegroups.com Subject: [nhibernate-development] Linq OrderBy and left joins I've been pondering this thread over on nh-users http://groups.google.com/group/nhusers/browse_thread/thread/1ff37a36e9f975ce?hl=en# To save you reading it all, the guy is try to do this: Session.Query<Project>().OrderBy(p.Type.Label).ToList() but due to the reference to p.Type there is a join being inserted, which means that there is some un-intentional filtering going on (he doesn't receive any results where p.Type is null). This is analogous to hitting a child reference within a select, for example Session.Query<Project>().Select(p.Type.Label).ToList() In this case, the provider (correctly, imo) generates outer joins to ensure that filtering is not taking place. In my view, filtering of the results should only happen if there is an explicit join or where clause. So I'm proposing that I process OrderBy clauses in the same way as I handle Select, and introduce outer joins as appropriate - this is technically a breaking change, hence the post here to see if you all agree. Cheers, Steve
