I understand you're working on the LINQ support. One question that I have is whether the LLBLGEN LINQ syntax extensions will allow the developer to write joins in LINQ syntax and have it automatically translated to PrefetchPaths (whereby minimizing the need to write the PrefetchPath code manually)...

Thanks

Prefetch paths aren't supported by the Linq syntaxis. I think Frans will add extension methods there. (http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=11257)

Prefetch paths aren't specifyable in linq, which will be a true challenge Regular Smiley. In short it will come down to a parser which parses an Expression tree into predicate objects, relations etc. and these elements are then passed to the right llblgen pro object (daobase or dataaccessadapter) to fetch the data. (http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=11129)

You could follow up the Linq to LLBLGenPro on-going series of articles at Frans blog: http://weblogs.asp.net/fbouma/

Joins won't be converted to prefetch paths as those are a different thing. Joins are a way to filter on a related entity.

Adding prefetch paths to Linq will be a challenge, but I hope it will be possible with extension methods.

Oops, sorry, I think I meant relationstouse... But prefetchpath functionality is an interesting question, too...

tolga wrote:

Oops, sorry, I think I meant relationstouse... But prefetchpath functionality is an interesting question, too...

The stuff like: var q = from c in md.Customers join o in md.Orders on ...

will indeed be converted to existing relations, otherwise a new dynamic relation (new class) will be created based on the predicate specified.

There are a couple of enhancementpoints for us: 1) prefetch paths INSIDE the linq query. This will be tricky to add, as path specifications are often multi-line due to the fact that prefetch path graphs have multiple branches (paths) and you need 1 line per path. So it's likely you'll first define the path and then do something like: var q = (from c in md.Customers select c).WithPath(path);

2) dynamic lists fetched as real objects, with hierarchies. Linq allows hierarchical projections so you can specify nested linq queries where the nested query is meant to specify the fetch for a nested set. Like this query: var query = from c in db.Customers select new { Name = c.ContactName, Orders = from o in db.Orders where o.CustomerID == c.CustomerID select o };

the Orders fetch is a nested query. Linq to Sql and Linq to Entities will both require MARS for this as they'll execute a new query for the orders on the open connection. This is of course a bit odd, if you consider that this is actually simply prefetch path fetching based on the predicate in the where specification. This will require a change in the merge routine but that shouldn't be too hard. I.o.w.: llblgen pro should be able to fetch the above query in 2 sql queries instead of #of customers +1

Determining what to do is the tricky part as the Expression tree elements aren't really suitable for easy parsing, because the tree doesn't contain a 'select' node, but a method call expression to a Select method. But we'll manage