2

There are quite a few questions on Stack Overflow about the Linq to Entity / Linq to SQL Sum extension method, about how it returns null when the result set is empty: 1, 2, 3, 4, 5, 6, 7, and many more, as well as a blog post discussing the issue here. I feel it is an inconsistency in the Linq implementation.

I am assuming at this point that it is not a bug, but is more or less working as designed. I understand that there are workarounds (for example, casting the field to a nullable type, so you can coalesce with ??), and I also understand that for the underlying SQL, a NULL result is expected for an empty result set.

But because the result of the Sum extension for non-nullable types is also non-nullable, why does the Linq to SQL / Linq to Entity Sum behave this way?

Improve this question
2
  • I wonder if it's a bug in the specification (also known as broken-by-design), or if that was just a bug in the code (i.e. this wasn't designed at all).
    – CodesInChaos
    Aug 20, 2014 at 16:23
  • @CodesInChaos That's kind of what I'm asking about.
    – Hannele
    Aug 20, 2014 at 19:00

1 Answer 1

Reset to default
3

The problem isn't that EF or LINQ2SQL return null for an empty set, it's that SQL returns null. Along those lines, what would you expect EF or LINQ2SQL to return when attempting to sum on a null value?

Generally, a null value is not a candidate for mathematical functions. Null usually means something along the lines of "unknown value" and is not the same as zero (the default value of an int or decimal in .NET). You can't perform math on it.

As such, it would be improper for the framework to decide to always substitute a default value for a null value and proceed to give you a misleadingly precise sum. Instead, the framework properly complains that the sum operation is impossible (because of the null value) and it is left to the caller to decide what to do in the case of a null value, using the techniques you have described and linked to in your question.

Improve this answer
14
  • 1
    Then how come it doesn't explicitly return a nullable value?
    – Hannele
    Aug 20, 2014 at 18:27
  • 5
    So then the question is why does SQL return null? An empty set is not "an unknown value," it's a set containing zero elements, and the proper sum of this is zero. This is well-understood, clearly-defined math. What's the rationale for the DBMS returning a mathematically incorrect result in this case?
    – Mason Wheeler
    Aug 20, 2014 at 18:38
  • 2
    TSQL Aggregate Functions (like SUM()) also ignore NULL values in a set that contains them, while apparently returning NULL for an empty set. That seems odd to me, too.
    – Eric King
    Aug 20, 2014 at 18:54
  • 1
    It's inconsistent with other .NET framework implementations - Linq to Object will return 0 if the list is empty. This has also been presented as a workaround in some places (casting to IEnumerable, then calling Sum), although it is inefficient if you only want the sum.
    – Hannele
    Aug 20, 2014 at 20:03
  • 1
    to convert the Queryable.Sum call to an Enumerable.Sum call and then calls it to do the sum. So Enumerable.AsQueryable().Sum() is just a long way to call Enumerable.Sum() when you aren't using an actual database provider based IQueryable. Which means calling Queryable.Sum on an empty sequence behaves differently based on Provider, which seems like a bad design decision.
    – NetMage
    Oct 10, 2018 at 21:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.