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

Optionally enable server-evaluation for non-correlated query fragments #23819

Closed
ajcvickers opened this issue Jan 5, 2021 · 4 comments
Closed
Labels
closed-out-of-scope This is not something that will be fixed/implemented and the issue is closed.

Comments

@ajcvickers
Copy link
Member

See #23764. We typically evaluate expressions on the client when they are not correlated to any database object. This greatly helps creation of efficient parameters. However, this can be problematic when the database evaluation returns different results than the database translation. This can be opted into in the place handling the translation--for example the NTS plugin in this case. However, it could also be useful to allow this be be opted into by the application.

@roji
Copy link
Member

roji commented Jan 5, 2021

@ajcvickers the NTS plugin can already opt specific methods out of client evaluation via evaluatable filters (I think this is what @smitpatel referred to in the meeting), so if we decide we want to always exclude certain methods, we can already do that.

This issue still makes sense as an application opt-out (i.e. via EF.ServerEval() or similar)

@ajcvickers
Copy link
Member Author

@roji Yes, that's tracked by #23764

@smitpatel
Copy link
Member

We can add this to design meeting if people want to discuss in detail.

  • We can do this if we come across an absolute scenario where this makes sense. (So this propose-close is not never but rather wait for feedback where other mechanism does not work)

The flipside of "forcing" server eval of some expression in the query is that, there needs to be server equivalent translation for it else it will be translation failure. Currently translation comes from core provider, plugins and UDFs.

  • UDFs are already excluded from evaluating on client.
  • DbFunctionExtensions we provide are also excluded (thanks to @roji)
  • Currently plugin/provider don't exclude expression from client eval if possible, but if they are aware of methods which can generate different result, they can add that too. Our evaluatable expression filter also takes plugins so plugin can exclude any expression too.

Only case right now where the opt-out would actually work where the code did not opt-out when adding translation by error. So we should wait for a case where this actually helps.

@AndriySvyryd
Copy link
Member

We discussed this in triage and the value proposition of having a general way of forcing server evaluation is low value and high cost. We'll handle specific cases like NTS when needed.

@ajcvickers ajcvickers added closed-out-of-scope This is not something that will be fixed/implemented and the issue is closed. and removed closed-not-needed labels Mar 10, 2022
@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
Labels
closed-out-of-scope This is not something that will be fixed/implemented and the issue is closed.
Projects
None yet
Development

No branches or pull requests

4 participants