> > from timeHeader in metaData.NonPresentTimeHeader where timeHeader.Id
> > == 6 join time in metaData.NonPresentTime on timeHeader.Id equals
> > time.HeaderId into timeJoin from joinedTime in
> > timeJoin.DefaultIfEmpty() select joinedTime
>
> > What might be a solution is to add a 'jointype' to the groupjoin class
> > of re-linq and switch it to 'left join' when you handle the
> > p=>DefaultIfEmpty() construct of a re-linq tree.
>
> Hi Frans,
>
> we could transform simple left-join-via-DefaultIfEmpty to left join
clauses
> in re-linq's QueryModel, but that would be a very simplistic solution that
> could not support any but the most straightforward LINQ clauses. (i.e.
only
> those where someone implements left join as they found out via Google, but
> for instance not any scenario where the query further references the
> intermediate join clause (timeJoin in your sample).
A simple, stupid, but illustrative example: ('ctxt' is
session.Linq... )
var q = from c in ctxt.Order
join o in ctxt.Order on c.CustomerId equals o.Customer.CustomerId
Into co // A
from x in co.DefaultIfEmpty() //B
select c;
Lines A and B form a SelectMany, due to the from in B. At the left side,
you'll have the group join in A and on the right side you have the right
side of the group join in A.
This can be transformed into keeping A, and using B to adjust the group
join. The main advantage is that the group join contains the selectors and
in C#'s case also the projection.
So if re-linq could transform this into (pseudo code!)
var q = from c in ctxt.Order
(left) join o in ctxt.Order on c.CustomerId equals
o.Customer.CustomerId Into co select c;
it would be a big win. Big problem is the code which references the
DefaultIfEmpty result as that has to be changed to references to the
right-side of the join.
It would help a lot, because it would make a join handler in a linq provider
much easier, in fact, an existing join handler (which can handle the normal,
'join') would likely already work.
> We think that DefaultIfEmpty is best solved in each back-end individually,
> but of course nothing stops anyone from extending the front-end to create
> that kind of QueryModel via an optional transformation step. Just be aware
> that this only takes you so far, it would probably result in the LINQ
> provider rejecting every use of DefaultIfEmtpy in joins that cannot be
> reduced to that pattern.
You mean:
var q = from c in ctxt.Order
from o in c.Orders.DefaultIfEmpty()
select c;
?
FB
