current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 0 down vote favorite

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?

share|improve this question
    
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 '14 at 16:23
    
@CodesInChaos That's kind of what I'm asking about. –  Hannele Aug 20 '14 at 19:00

1 Answer 1

up vote 2 down vote

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.

share|improve this answer
1  
Then how come it doesn't explicitly return a nullable value? –  Hannele Aug 20 '14 at 18:27
3  
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 '14 at 18:38
    
@MasonWheeler That's a good (and different) question. I don't know why SQL would return NULL in this case. I'm just assuming that's the case anyway, based on the posts linked to in the question, because I've not personally come across that situation any time in recent memory. I just know that EF and LINQ2SQL behave the way I would expect, and consistent with other .NET code. –  Eric King Aug 20 '14 at 18:47
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 '14 at 18:54
    
From a practical standpoint, it might be useful to distinguish between zero (being a perfectly valid result for some non-empty set) and null (indicating an actual empty set), even if 0 is a perfectly reasonable result for an empty set. –  Robert Harvey Aug 20 '14 at 19:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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