-
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
Query: Throw better exception when aggregate operation hits client eval #15937
Comments
Going to work on this. |
@divega Message proposal:
Feedback? And fwlink... |
I would suggest using AsEnumerable/AsAsyncEnumerable. ToList also works but creates object which may not be needed. And ToListAsync would involve await keyword. Those patterns could go to fwlink. |
I would also wish we could just suggest AsEnumerable and AsAsyncEnumerable, but the problem with the latter is that any further LINQ query composition on the client requires adding System.Linq.Async as a dependency to the application. So in that sense ToListAsync() can be a simpler thing to propose, even if it requires awaiting before doing any in-memory proccesing. FWIW, in the latest version of the LINQ workarounds that I included in the Preview 8 blog post I thought about this and I ended up deciding to mention all 4 methods. LINQ to Objects doesn't have hyphens. Re the fwlink, it is less than ideal, but given that we don't have versioning in our documentation perhaps we should keep the same fwlink we had in the warning for client evaluation before (https://go.microsoft.com/fwlink/?linkid=2097910), which points to https://docs.microsoft.com/ef/core/querying/client-eval, and update the article to add a section for EF Core 3.0 and move the current content to a section about previous versions. |
@divega @smitpatel Based on the blog text:
I agree with leaving |
I changed my mind about the fwlink. It is more future-proof to create a new one for 3.0, even if for now they point to the same page: https://go.microsoft.com/fwlink/?linkid=2101038.
Good point. I created dotnet/EntityFramework.Docs#1648 to track this. |
Some tests still throwing a bad message after initial work here:
|
SqlException since it is invalid SQL. I suggest, verify as SqlException only. In past we identified such scenario and did client eval. No point of doing work of identifying this pattern. |
Putting this on the backlog since not generating SQL (instead throwing early) that won't work is better than letting it throw, but this isn't high priority. (Until feedback says it is.. ;-)) |
I have some similarly invalid SQL generated via trying a |
Am going to go ahead and close this. @ajcvickers already improved the exception message for client eval (#17247); regarding "Cannot perform an aggregate function on an expression containing an aggregate or a subquery" specifically (which is a SQL Server limitation error), we should try to rewrite the query to work (#34256), rather than trying to throw a better exception message; identifying the specific case where the SQL Server error would be produced would be half-way towards fixing the issue in any case. |
No description provided.
The text was updated successfully, but these errors were encountered: