Skip to content
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

Query: GroupBy in-memory execution must honor result retrieved by the query executed against database #10064

Closed
dozer75 opened this issue Oct 13, 2017 · 4 comments

Comments

@dozer75
Copy link

dozer75 commented Oct 13, 2017

When a query that uses a db function is grouped using GroupBy in linq the C# function is executed when the GroupBy is executed in-memory even if it is executed in the database query already. It should not call the db function in these scenarios and rather use the value returned by the query.

This is the LINQ statement that causes the exception. Full code is attached in zip file.

context.SimpleTables.Select(row => new
                                   {
                                       row.Id,
                                       row.Val1,
                                       row.Val2,
                                       Sum = Functions.MySum(row.Val1, row.Val2)
                                   })
                     .GroupBy(row => row.Id, row => new
                                                    {
                                                        row.Val1,
                                                        row.Val2,
                                                        row.Sum
                                                    })
                     .ToArray();

Steps to reproduce

The solution is in whole added to this issue. There is a database script that creates the needed data to reproduce it on SQL Server. The project is an xUnit test that will fail with the NotSupportedException that is specified in the db function definition.

EFCore21GroupByDbFunctions.zip

Further technical details

EF Core version: 2.1.0-preview1-27020 (The issue is also in 2.0)
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Windows 10
IDE: Visual Studio 2017.3

@ajcvickers
Copy link
Member

Triage: @smitpatel to investigate whether this should be supported (and if so whether it can be done without relinq changes), or whether writing the GroupBy in a different way is a more practical approach.

@smitpatel
Copy link
Member

This is because of how the ReLinq generates QueryModel

      Compiling query model:
      '(from Blog row in DbSet<Blog>
      select new <>f__AnonymousType1<int, int, int, int>(
          [row].Id,
          [row].Val1,
          [row].Val2,
          int MySum(
              a: [row].Val1,
              b: [row].Val2)
      )).GroupBy([row].Id, new <>f__AnonymousType2`3(Val1 = [row].Val1, Val2 = [row].Val2, Sum = MySum([row].Val1, [row].Val2)))'

This causes MySum to evaluate on client during element selector.

@smitpatel smitpatel removed this from the 2.1.0 milestone Oct 13, 2017
@dozer75
Copy link
Author

dozer75 commented Oct 14, 2017

Have a hard time seeing why it shouldn't be supported, the data is retrieved from the databasse before grouped in memory, so why not use the inline result. Limited group by support with in-memory calculations was acceptable for us, but this is a showstopper for further usage of Entity Framework Core :/

@ajcvickers ajcvickers added this to the 2.1.0 milestone Oct 16, 2017
@ajcvickers ajcvickers assigned anpete and unassigned smitpatel Oct 16, 2017
@ajcvickers ajcvickers modified the milestones: 2.1.0-preview1, 2.1.0 Jan 17, 2018
@ajcvickers ajcvickers modified the milestones: 2.1.0, Backlog Jan 26, 2018
@ajcvickers ajcvickers changed the title GroupBy in-memory execution must honor result retrieved by the query executed against database Query: GroupBy in-memory execution must honor result retrieved by the query executed against database May 16, 2018
@smitpatel
Copy link
Member

Duplicate of #17068

@smitpatel smitpatel marked this as a duplicate of #17068 Sep 4, 2019
@smitpatel smitpatel removed this from the Backlog milestone Sep 4, 2019
@ajcvickers ajcvickers reopened this Oct 16, 2022
@ajcvickers ajcvickers closed this as not planned Won't fix, can't repro, duplicate, stale Oct 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants