I agree with the outer join behavior, as it's the safest from a data point of view.
In fact, I recently wrote a patch for DynamicQueryable that provides the same behavior when using Linq-to-objects (with some limitations) Available at http://gist.github.com/468077. Since it's originally copyrighted by Microsoft (and I couldn't find a license in the zip), I'll take it down if they request it. Diego On Thu, Jul 8, 2010 at 06:24, Steve Strong <[email protected]> wrote: > 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 >
