With no explicit join at all, there's no justification for filtering
the result set. This statement just says take all users, then for each
hand me their ID and role name. A query on IEnumerable would fail on
the .Name access, but if you reduce it to the role itself, you'll see
that LINQ to SQL does just as it should. The automatic null
propagation is nice, but not required.
While there are no specs about the semantics of LINQ statements in a
general case (they even differ slightly between C# and VB), I guess
deviations from LINQ to Objects should be well-grounded.
I tried to bring that up twice ("equals" and "count" semantics), if
anyone's interested I'd still like to discuss this. (Although I have
to say I'm not into NH that much yet, and re-linq is really agnostic
to most of these questions - we do have the same issues in re-store,
our own ORM)
Cheers,
Stefan
http://relinq.codeplex.com
On Dec 10, 10:15 pm, Fabio Maulo <[email protected]> wrote:
> do you think that the LINQ2SQL behaviour is correct ?
> Without a specific "left join", IMO, the correct behaviour should be a inner
> join.
>
> 2009/12/2 Steve Strong <[email protected]>
>
>
>
>
>
> > Just porting over the last few tests from the 1.0 provider, and came across
> > this one:
>
> > from user in db.Users
> > select new
> > {
> > Id = user.Id,
> > RoleName = user.Role.Name
> > };
>
> > pretty simple stuff, and I generate the following HQL:
>
> > select u.Id, u.Role.Name from User u
>
> > and then stick this through a result transformer to build the required
> > anonymous type. The problem is that it does not return any users that do
> > not have a Role, since the sql generated essentially joins the User & Role
> > tables.
>
> > If you run the same query in Linq2Sql, you get back all users, with a null
> > RoleName for those that have no role. It's generating an outer join in the
> > sql to achieve this. I can tweak the HQL to be this:
>
> > select u.Id, u.Role.Name from User u left outer join u.Role
>
> > which then generates the correct SQL but still only returns results where
> > Role is not null. The v1.0 provider is going through the Criteria API,
> > where doing a projection of "Role.Name" is returning null when there is no
> > role.
>
> > The question is whether there is any simple syntax to get HQL to behave in
> > the same way as the criteria API? I've tried a few combinations, but every
> > time I reference u.Role I fail to get rows back where that is null. I'm
> > hoping I'm missing something obvious here!
>
> > Cheers,
>
> > Steve
>
> --
> Fabio Maulo- Hide quoted text -
>
> - Show quoted text -
