search

dotnet / efcore

EF Core is a modern object-database mapper for .NET. It supports LINQ queries, change tracking, updates, and schema migrations.
https://docs.microsoft.com/ef/
MIT License
13.78k stars 3.19k forks source link

Query: Provide a way to indicate that part of a query should translate to server or throw #24509

Open AndreyYurashevich opened 3 years ago

AndreyYurashevich commented 3 years ago

I enjoy using EF Core 5.0 with Microsoft.EntityFrameworkCore.SqlServer on .NET 5.0, but it feels like Client evaluation in the top-level projection does not really fit into my workflow and I would like to be able to disable (either globally or on a per-query basis) falling back to client evaluation completely. By disabling I really mean any way to track it: throwing exceptions, issuing warnings, etc. I couldn't find any references to this possibility so any information would help.

roji commented 1 year ago

This issue is in the Backlog milestone. This means that it is not planned for the next release (EF Core 8.0). We will re-assess the backlog following the this release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources. Make sure to vote (👍) for this issue if it is important to you.

johnnyjob commented 10 months ago

Just add an option to disable client-side eval. Pragmatic programmers want predictable SQL queries from their LINQs, that's why. You can continue to evaluate on the client by default to keep backward compatibility.

roji commented 10 months ago

Just noting that there are two kinds of client-eval: on input (fragments in the LINQ query which can get evaluatable client-side and then sent as parameters with the query) and on output (final projection). I'm assuming nobody has an issue with the former.

janseris commented 10 months ago

@roji please don't avoid the discussion. The goal is just an option to disable silent loading of unwanted data which is what EF does now when the projection is not inline, what @johnnyjob writes as well. Whatever it is called.

johnnyjob commented 10 months ago

Just noting that there are two kinds of client-eval: on input (fragments in the LINQ query which can get evaluatable client-side and then sent as parameters with the query) and on output (final projection). I'm assuming nobody has an issue with the former.

I cannot tell for everybody, but I would like to avoid client side evaluation in the final projection.

stevendarby commented 10 months ago

@roji well... I think this issue is definitely about the latter and there's much more demand for that. But the former is interesting....

As I understand it, client evaluation on input can sometimes involve compiling an expression and invoking it. For those wanting to eek out every last bit of performance, perhaps they would appreciate a warning or way to disable this, and be guided to evaluate into a variable outside of the LINQ query and use that variable instead - which I think would be less costly? But even if this made sense, it'd need tracking in a separate issue I think.

roji commented 10 months ago

It's a good question... For anything more complex than the simplest fragments (i.e. member access on a closure captured variable, aka a parameter) EF internally invokes the LINQ expression tree interpreter to evalute the tree fragment. This certainly isn't the most efficient thing in the world, but it's also a single up-front operation (per parameter) that's very, very unlikely to matter in any non-contrived scenario... I really don't see us adding a warning/opt-in for this - but it would be good to hear other opinions.