> oh I agree. Similar to the thing we saw last week with the > skip/take/count stuff.
Which was a problem reported for the old contrib provider. A coworker just pointed that out, in the heat of the discussion nobody seemed to notice ;-) > LoC measured in ndepend (so true LoC) or from sourcefiles? My > linq > provider has in ndepend 6500 LoC. In sourcecode, it's a multiple of > that, > but I'm very verbose haha :D Source files, counting comments and license headers too. Grain of salt recommended. > But kidding aside, I see the advantage re-linq brings, no > question > about that, I just wonder (and still do) where the complex linq stuff > is > solved: in re-linq or does a user of re-linq have to solve these probs? > > I'll have a look at re-linq to see what kind of trees it produces > with some of the 'pain' linq queries like: (adventure works) (insulting query removed) In the frontend, I'm pretty sure we handle that. You'll get a nice query model with neatly separated subqueries. As for the backend: With a quick look I can't see anything that shouldn't work. (Fabian may.) But we'd have to try, this query was built to destroy LINQ providers after all ;-) I suggest you take that question to [email protected]. I don't want to hijack this list here. > it still pains me to see this one fail in my linq provider (among > several other 'headache' queries), but then again, it's not a common > query > ;) (it's a reproduction of a problem with a real-life query, so it > doesn't > make sense, but illustrates a couple of nasty issues) I can't see these issues, just an annoying level of subquery nesting, which re-linq should handle gracefully. But maybe I'm missing something. Ask the man! (The frontend will not resolve the DefaultIfEmtpy to a left join though! I think I discussed that with Fabian once, but my memory fails me.) > If re-linq can solve that, it would indeed be rather 'easy' as > in: > way easier than creating it using the 'warren' method with expression > objects which are converted into other expression objects etc. which > leads > to painful conversions. That's what we're trying!
