Hi,

On the LLBLGenPro feature list I see "Full LINQ support".

First of all: what is the definition of "Full LINQ support" ?

Secondly: I scanned the LLBLGenPro LINQ provider API and encountered that not all operators are supported (it could be that I missed something, so please correct me if I am wrong )

The following LINQ operators could not be found:

• ToSequence
• EqualAll
• Empty
• Range
• Repeat
• ThenBy
• ThenByDescending

Why is LLBLGenPro claiming "Full LINQ support" then ?

DrDelete wrote:

Hi, On the LLBLGenPro feature list I see "Full LINQ support". First of all: what is the definition of "Full LINQ support" ?

The remark is made because many of our competitors say they support linq while they don't: with their providers you either have to run the majority of the query in memory or they don't work at all. With our provider that's not the case: we support all constructs which are convertable to a SQL query.

See for a more in depth discussion about this: http://weblogs.asp.net/fbouma/archive/2008/06/17/linq-to-llblgen-pro-feature-highlights-part-1.aspx

And yes, I take this very seriously. The thing is that we worked very hard to create a linq provider which always works (give or take a bug here and there) and if we then say 'We support linq' it's not different than anybody else out there, however the majority of those other providers can't do what an every day linq programmer wants to do with linq.

Secondly: I scanned the LLBLGenPro LINQ provider API and encountered that not all operators are supported (it could be that I missed something, so please correct me if I am wrong )

You're wrong. .

The following LINQ operators could not be found:

• ToSequence
• EqualAll
• Empty
• Range
• Repeat
• ThenBy
• ThenByDescending Why is LLBLGenPro claiming "Full LINQ support" then ?

ThenBy and ThenByDescending are supported as normal ordering methods so I don't really understand why you missed those. (Preprocessor.HandleQueryableExtensionMethod is your friend)

ToSequence, EqualAll, Empty, Range, Repeat: MSDN can't find these. I think you are looking at the .NET 4.0 beta 1 docs. It may be no surprise we don't support .NET 4.0 yet.

ToSequence is likely not going to work in sql, as sql is not sequence based. EqualAll seems to be a .NET equivalent of sql's ALL operator, which has not that much usage (though llblgen pro supports ALL and the Linq operator 'All()' which IMHO sounds like an alternative). Range, is a way to express a range of values. We'll support that when .NET 4.0 arrives. Repeat... no idea what that does.

I.o.w.: show me a IQueryable<T> operator (besides union which isn't supported as our framework doesn't support it) which is convertable to sql which isn't supported.

(...)

You are right, I missed the ThenBy operators in LLBLGenPro .

The operator list that I was missing in LLBLGenPro is coming from a list provided by a link within the NHibernate LINQ provider online documentation, see

http://www.hookedonlinq.com/LINQtoObjects.ashx

there you can find also more detail about each operator by this link:

http://www.hookedonlinq.com/StandardQueryOperators.ashx

I don't think the operators that were missing in LLBLGenPro are coming from a new specification in EF 4.0 beta 1, but are already there in the original specification from May 2006.

From the list of operators that is provided there I checked each operator with LLBLGenPro for coverage.

I think these links are talking about LinqToObjects, not LinqToSQL, am I right?

Walaa wrote:

I think these links are talking about LinqToObjects, not LinqToSQL, am I right?

Yes, these are LinqToObjects LINQ operators.

Has LinqToSQL less support on LINQ operators than LinqToObjects ?

(edit) I found the Range method as an extension method of IEnumerable<T>, my bad. I don't see we support it, though creating an array from the range is supported (to pass in a range of values to filter on in a Contains call for example)

DrDelete wrote:

(...) You are right, I missed the ThenBy operators in LLBLGenPro . The operator list that I was missing in LLBLGenPro is coming from a list provided by the NHibernate LINQ provider doc, see http://www.hookedonlinq.com/LINQtoObjects.ashx

nhibernate linq provider? That's what I mean with others saying they have a linq provider while it can't even do a join. But that site isn't about linq to nhibernate, it's a general site about linq.

there you can find also more detail about each operator by this link: http://www.hookedonlinq.com/StandardQueryOperators.ashx I don't think the operators that were missing in LLBLGenPro are coming from a new specification in EF 4.0 beta 1, but are already there in the original specification from May 2006.

There are no missing operators. Open MSDN of vs.net 2008, type in the index 'EqualAll' or 'ToSequence' and see that nothing turns up. all operators are defined on IQueryable<T> or on it's parent type IEnumerable<T>

I spend 9+ months full time writing this provider, I think I know which extensionmethods and expression classes are used in expression trees. Why don't you believe me when I say they're not from .NET 3.5? Did you even look them up in the .NET 3.5 msdn? As they're not there, I assumed they're from .NET 4.0, as I don't know them and have never seen them before as well (except Range perhaps)

To answer your doubt, please click on the ToSequence link on the above page: http://www.hookedonlinq.com/ToSequenceOperator.ashx

You'll see it's an old name. Today it's AsEnumerable, which of course makes no sense in a sql query.

From the list of operators that is provided at the NHibernate LINQ page I checked each operator with LLBLGenPro for coverage.

Trust me, we do have support for all possible linq operators, and Expression classes which make sense in a database environment. So for example SequenceEqual isn't supported with a reason, that's explained in the docs. Union is the only one missing which could make sense, and we don't support that because the runtime framework doesn't support union.

DrDelete wrote:

Walaa wrote:

I think these links are talking about LinqToObjects, not LinqToSQL, am I right?

Yes, these are LinqToObjects LINQ operators. Has LinqToSQL less support on LINQ operators than LinqToObjects ?

Patrick, you should read my first post again. The set of extension methods on IEnumerable<T> which are inherited by IQueryable<T> not always make sense in a database context because a database doesn't use sequences, it uses sets. Linq to objects uses IEnumerable<T> sources, all other linq operators use IQueryable<T> sources. Linq to objects uses sequences in-memory as an iterator has an order, it's a sequence. This allows things like SequenceEqual to be used, or Reverse, while or IQueryable<T> sources they make no sense, as a set of entities isn't a sequence, it's a set and SQL doesn't support sequence operators (unless you define a cursor)

Linq to sql also doesn't support ElementAt(), which we support (as it's the same as Skip(n).Take(1) ), though they support Union which we don't. Union is subjective though, often you can't create a union query anyway in SQL because the sequence oriented linq tree isn't convertable to SQL in a way that the results will be the same.

Besides that, what is exactly the question you want to ask, because I've provided you with a lot of info but you apparently don't see that as answering your question.

whow... take it easy Frans, I know you have good support of LINQ, no doubt about that .

Most O/RMs that I am reviewing now only support a very small amount of LINQ operators. In my review I create a list with all the LINQ operators available and I show there if they are implemented by the O/RM, that's all. This means that some of the operators are not implemented by any O/RM at all, so that should not be a problem in the O/RM selection-process.

DrDelete wrote:

whow... take it easy Frans, I know you have good support of LINQ, no doubt about that .

Sorry, you just struck a nerve. Writing the linq provider was hell, and after that, it didn't seem to matter much in terms of 'this supports linq and that doesn't', as most people who don't look closely think most o/r mappers support linq in full (as it's advertised as such). But as we're perfectionists, I know I also couldn't bear the thought of having a half-baked linq provider because 'the rest does that too' either...

Most O/RMs that I am reviewing now only support a very small amount of LINQ operators. In my review I create a list with all the LINQ operators available and I show there if they are implemented by the O/RM, that's all. This means that some of the operators are not implemented by any O/RM at all, so that should not be a problem in the O/RM selection-process.

In our docs, we've documented all operators which aren't supported, and the reason why. I think it will help with your review as the reasons often explain that the operator makes no sense in SQL or couldn't be properly implemented. Like 'reverse'. XPO for example supports Reverse, but it's not possible to get a proper result in all cases by simply reversing the ordering. What if there are duplicates in the resultset? Btw the EF doesn't support Contains(), in case you didn't know that. I didn't know till recently, and it's surprising they didn't implement Contains, but apparently it's complex to do for their framework, not sure.

It is much work to review O/RM on LINQ support.... for example the NHibernate LINQ provider. Intellisense shows coverage for a specific LINQ operator( like the join operator) and in runtime it throws an NotImplementedException, arghhhhhhhh

But thanks for your advise !

DrDelete wrote:

It is much work to review O/RM on LINQ support.... for example the NHibernate LINQ provider. Intellisense shows coverage for a specific LINQ operator( like the join operator) and in runtime it throws an NotImplementedException, arghhhhhhhh But thanks for your advise !

Outside MS, there are just a couple of full linq providers, the rest is simply limited and will fail at runtime. Genom-e of techtalk and LLBLGen Pro are the main o/r mappers with a full linq provider with coverage for almost everything, where I don't know if genom-e covers the stuff I highlighted in the link to my blogpost.

For nhibernate, you can give it up, until the guy who wrote the AST parser for v2.1 will succeed in creating a linq provider so that's not some time soon.