Tuesday, November 11, 2008 2:02 AM
Why am I getting this exception? The method 'single' is valid. The exception suggests to use 'First' instead, but 'First' is not what I want. I want 'single'. Any particular reason this is not supported?
Tuesday, November 11, 2008 2:48 AM
yeah Single is not supported. You have to use First operator. The explanation that i read was it's not possible. Wonder how linq to sql team did it.
If you want to follow up with that thread, you can search for First on the forum
Tuesday, November 11, 2008 2:57 AM
Yes I am in fact converting my code from Linq to Sql to EF, and it was working. So far I'm not too thrilled about this conversion. I have many chains of ".Include(xxxx).Include(yyy).Include(zzz)" whereas before I had just a few LoadWith<> statements. But that's another post . Thanks
Tuesday, November 11, 2008 4:48 AM
Sorry you are having trouble converting the Single operator. We are working on making sure we support this in Dev10. Eager loading via something like DataLoadOptions is also being considered.
In the meantime, you can implement an extension method on IQueryable that will give you simple Single functionality, like so:
public static TElement Single<TElement>
(this IQueryable<TElement> query)
if (query.Count() != 1)
throw new InvalidOperationException();
// Use it like this
Product prod = (from p in db.Product
where p.ProductID == 711
Hope this helps.
Faisal Mohamood | Program Manager | Data Programmability
Tuesday, November 11, 2008 1:22 PM
Thanks for the reply. Sorry that I am frustrated when I posted that. I invested a lot of time in Linq to Sql but I'm sure that EF is good too. It's just dealing with yet another learning curve on yet another technology.
Tuesday, November 11, 2008 5:06 PMModerator
Just to clarify, Single on the top level projection is perfectly possible and relatively easy to implement. Supporing Single anywhere in the query with full semantics (i.e. throw if there is more than one element) is quite complicated if not impossible.
Tuesday, November 18, 2008 3:38 AM
SingleOrDefault is actually easier to implement in the body of a query than you might think.
Take this query for example:
var query = from c in db.Customers
where c.Orders.SingleOrDefault().OrderDate.Value.Year == 1997
This is obviously bogus. It should error since I did nothing to pick out out just one order.
LINQ to SQL translates this to:
SELECT [t0].[CustomerID], [t0].[CompanyName], [t0].[ContactName], [t0].[ContactTitle],
[t0].[Address], [t0].[City], [t0].[Region], [t0].[PostalCode], [t0].[Country], [t0].[Phone], [t0].[Fax]
FROM [dbo].[Customers] AS [t0]
WHERE DATEPART(Year, (
FROM [dbo].[Orders] AS [t1]
WHERE [t1].[CustomerID] = [t0].[CustomerID]
)) = @p0
The important part is highlighted. Single and SingleOrDefault turn collections into single objects. Yet, like collections they don't often have meaning in a query unless they are part of the output. If they are part of the output then the materialization logic handles identifying the error and throwing an exception. If not, then it is nearly certain that some operation must follow the call to Single or SingleOrDefault less the expression be erroneous or non-translatable for other reasons. If a member access is done on the singleton sub-query it is converted in a SQL scalar sub-query. Scalar sub-queries do error when they resolve to more than one row. The above query throws this exception straight out of the server.
"Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression."
The server doesn't error, though, when no rows were returned for the subquery. So the semantic for scalar subqueries is similar to SingleOrDefault.
Tuesday, November 18, 2008 9:03 PM
Thanks for explaining these concepts in depth. I am big fan of your work and blog and I am sure lot of developers in the community are Indebted to your invaluable work in linq to sql. Too bad i had to let it go and move to EF as microsoft announced EF as the perferred data access technology. Hopefully some future release EF will live up to the par which linq to has set and will better translate queries to sql as linq to sql does.
Tuesday, November 18, 2008 9:18 PM
Seems like MS killed the wrong framework. Anybody else notice VS 2008 steep price discounts lately? I wonder why. MS makes decisions based on politics and ignores what developers actually want.
Thursday, December 04, 2008 2:14 AMModerator
As Matt very well explains, SingleOrDefault can be implemented using scalar subqueries. The LINQ to Entities team is fully aware of this pattern, but currently Entity Framework does not support representing scalar subqueries at the provider level (although that was originally in the plans).
Adding this new capability to the provider model would mean that provider writers would have to react by introducing appropriate native query translations (different database engines may have different levels of support for scalar subqueries in different contexts in a query). Once we get that piece in place, supporting SingleOrDefault inside the query will be relatively simple for us.
My assertion that Single with full semantics is complicated still holds because, as Matt noted, with this method there is no exception when the subquery yields no results. The example I gave between parentheses was wrong, though, and it is clear that adding support just for SingleOrDefault inside the query would address an interesting subset of scenarios.
We have a very long list of features we want to add to the next versions of Entity Framework, and many of them are related to improving the programming experience in Object Services, including the LINQ support. The more we hear these issues from customers, the easiest if for us to prioritize in which features we should invest first.
So, thanks for the feedback!