LINQ and SQL in general.

[Frans Bouma [C# MVP]]

Right. Definitely bad. I'm certainly not trying to defend LINQ to SQL
as great in all respects - it's definitely a "v1" product, for
starters.

Don't buy the 'it's a v1 product' excuse! It's not a v1 product, it's
taken them a couple of previous attempts to get this far, so I don't
see how this can be a v1 product. Then again, there are enough examples
out there which prove that it can be done without a lot of hassle so
why they didn't implement it is beyond me.

Of course, in the above case you could probably get away with
fetching all the necessary fields from all the rows of the
appropriate tables, then joining it all up in memory. Not so each
when you only want particular rows though

every nested set is a query on its own. You can obtain a correlation
filter in the nested set and use that with an EXISTS query or IN query
on the parent set This limits the nested set on the rows related to
parents you've fetched. You can then either build an in-memoryh lambda
to compare rows or build 2 hash sets and compare hashes.

What's odd is that this is the way you have to do eager loading
anyway, so they have written the code already. At least, more or less
(as their eager loading code isn't up to par)

Does the Entity Framework do any better on this, do you know?

I don't know about the nested sets in projections, probably not. They
do have an '.Include()' extension method if I'm not mistaken which
allows you to specify related entities to fetch inside the query, using
eager loading. I'm not sure how they'll do that though (i.e. with the
same approach as linq to sql or with a better approach).

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------