Question

Is VB.NET’s Aggregate query fatally flawed when used as the first (outer) clause of a Linq expression with multiple Into clauses because each Into clause is executed separately?

The “obvious” answer to SELECT MIN(ZoneMin), MAX(ZoneMin) FROM Plant in LINQ to SQL is

Dim limits = Aggregate p In Plants Select p.ZoneMin Into Min(), Max()

However, this answer actually retrieves each of Min and Max (and if you include other aggregate functions like Count and Average) in separate SQL queries. This can be easily seen in LINQPad.

Is there a transaction (or something else making these queries atomic) not shown by LINQPad, or is this a race condition waiting to happen? (And so you have to do the tricks shown in the answer to the above question to force a single query that returns multiple aggregates.)

In summary, is there a LINQ-to-SQL query using Aggregate that returns multiple aggregate functions in a single (or at least “atomic”) query?

_{(I also say “obvious” because the obvious answer to me, Aggregate p In Plants Into Min(p.ZoneMin), Max(p.ZoneMin), actually retrieves the whole table twice, even when optimised, and then uses the Linq-to-Entities Min and Max to obtain the result 🙁 )}

_{I thought Aggregate wasn’t VB-specific, but it looks like C# does not have this query expression, so I’ve changed the .net to vb.net.}

Answer 1

To answer my broader question: is Aggregate broken for producing separate SQL queries without transactions?

All of LINQ can cause that if you don’t carefully adjust your queries to only result in a single SELECT, and that may not be possible, without “giving up”, retrieving a larger result in a single query and then using Linq-to-Objects to aggregate or otherwise manipulate the data. This ‘query’ for example.

So it is, in general, up to the programmer to ensure transactions are added around LINQ queries that may cause multiple queries. We just need to know for sure which LINQ queries may transform into multiple SQL queries.