-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect SQL generated for Count over Group By (EFCore 2.1) #12351
Comments
Expected SQL SELECT COUNT(*)
FROM (
SELECT [p].[AccountId] AS [Account], Sum([p].[Value] AS [Total]
FROM [Payments] AS [p]
GROUP BY [p].[AccountId]) AS [t] |
@mpetito - As a work-around you can just use distinct instead of group by like this |
…re 2.1) There was two problems here: - we were not lifting a select expression that had a GroupBy-Aggregate pattern, and another result operator was composed on top, - we were not propagating RequiresStreamingGroupBy flag to a parent QM, when we lifted a client group by subquery, which could result in the client methods being wiped out if Count/LongCount was composed on top.
…re 2.1) There was two problems here: - we were not lifting a select expression that had a GroupBy-Aggregate pattern, and another result operator was composed on top, - we were not propagating RequiresStreamingGroupBy flag to a parent QM, when we lifted a client group by subquery, which could result in the client methods being wiped out if Count/LongCount was composed on top.
@maumar This issue is approved for patch and the release\2.1 branch is now open for merging. Please ensure:
|
…re 2.1) There was two problems here: - we were not lifting a select expression that had a GroupBy-Aggregate pattern, and another result operator was composed on top, - we were not propagating RequiresStreamingGroupBy flag to a parent QM, when we lifted a client group by subquery, which could result in the client methods being wiped out if Count/LongCount was composed on top.
…re 2.1) There was two problems here: - we were not lifting a select expression that had a GroupBy-Aggregate pattern, and another result operator was composed on top, - we were not propagating RequiresStreamingGroupBy flag to a parent QM, when we lifted a client group by subquery, which could result in the client methods being wiped out if Count/LongCount was composed on top.
…re 2.1) There was two problems here: - we were not lifting a select expression that had a GroupBy-Aggregate pattern, and another result operator was composed on top, - we were not propagating RequiresStreamingGroupBy flag to a parent QM, when we lifted a client group by subquery, which could result in the client methods being wiped out if Count/LongCount was composed on top.
…re 2.1) There was two problems here: - we were not lifting a select expression that had a GroupBy-Aggregate pattern, and another result operator was composed on top, - we were not propagating RequiresStreamingGroupBy flag to a parent QM, when we lifted a client group by subquery, which could result in the client methods being wiped out if Count/LongCount was composed on top.
…re 2.1) There was two problems here: - we were not lifting a select expression that had a GroupBy-Aggregate pattern, and another result operator was composed on top, - we were not propagating RequiresStreamingGroupBy flag to a parent QM, when we lifted a client group by subquery, which could result in the client methods being wiped out if Count/LongCount was composed on top.
…re 2.1) There was two problems here: - we were not lifting a select expression that had a GroupBy-Aggregate pattern, and another result operator was composed on top, - we were not propagating RequiresStreamingGroupBy flag to a parent QM, when we lifted a client group by subquery, which could result in the client methods being wiped out if Count/LongCount was composed on top.
…re 2.1) There was two problems here: - we were not lifting a select expression that had a GroupBy-Aggregate pattern, and another result operator was composed on top, - we were not propagating RequiresStreamingGroupBy flag to a parent QM, when we lifted a client group by subquery, which could result in the client methods being wiped out if Count/LongCount was composed on top.
…re 2.1) There was two problems here: - we were not lifting a select expression that had a GroupBy-Aggregate pattern, and another result operator was composed on top, - we were not propagating RequiresStreamingGroupBy flag to a parent QM, when we lifted a client group by subquery, which could result in the client methods being wiped out if Count/LongCount was composed on top.
…re 2.1) There was two problems here: - we were not lifting a select expression that had a GroupBy-Aggregate pattern, and another result operator was composed on top, - we were not propagating RequiresStreamingGroupBy flag to a parent QM, when we lifted a client group by subquery, which could result in the client methods being wiped out if Count/LongCount was composed on top.
This problem still exists in 2.2, but there is another workaround, maybe helpful for others |
@HarutyunI thanks for your workaround, it works correctly on 2.2. |
EFCore 2.1 generates incorrect sql if you perform a
Count
operation on a queryable which uses the newGroupBy
translation. Given a query of the formqueryable.GroupBy(...).Count()
, EF performs a count within the groups instead of a count of the groups.Produced SQL which is incorrect:
Expected SQL similar to:
It may seem unusual to construct an EF query in this way. However, this issue surfaced when using
GroupBy
in a query for a paged list and I believe this to be a relatively common case. In my project the paging algorithm has no knowledge of the underlying query. The query is executed first withCount
to get the total count of records, and again withTake
/Skip
to get the current page of records.Steps to reproduce
I've created a small project to reproduce the issue: https://github.com/mpetito/efcore-2.1-groupby
Given the following seed data:
This query gives the incorrect count of groups:
The correct count is 3 when grouping by AccountId. The count of 1 is arrived at because the first group itself has a count of 1, and EF must be taking the first result row for the count (discarding any additional result rows).
Further technical details
EF Core version: 2.1.0
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Windows 10 / SQL Server 2016
The text was updated successfully, but these errors were encountered: