Where I've been unsre as to the correct behaviour, I've been using Linq-to-Sql as my guide - Linq-to-objects, although better defined, doesn't really map so well to the database world, things like the null reference exception that would indeed happen with these queries being a good example.
On Thu, Jul 8, 2010 at 11:50 AM, Richard Brown (gmail) < fluke...@googlemail.com> wrote: > 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 <srstr...@gmail.com> > *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 > >
