-
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 : ToString() method that takes a formatter argument should do client evaluation #7364
Comments
…ent should still be translated on the client Fix is to only translate ToString calls that have no arguments. Ones with the arguments will be evaluated on the client.
…nerate correct SQL if query also contains optional navigation Problem was that optional navigation is translated to GroupJoin which in turn forces materialization on entire entity. This causes Distinct to be applied on all columns of that entity, even if the customer specified a subset of columns to perform Distinct on. Fix is to always perform Distinct on the client if the query also contains GroupJoin
…nerate correct SQL if query also contains optional navigation Problem was that optional navigation is translated to GroupJoin which in turn forces materialization on entire entity. This causes Distinct to be applied on all columns of that entity, even if the customer specified a subset of columns to perform Distinct on. Fix is to always perform Distinct on the client if the query also contains GroupJoin
We could consider actually supporting translation in some specific cases. |
…ent should still be translated on the client Fix is to only translate ToString calls that have no arguments. Ones with the arguments will be evaluated on the client.
change translating ToString with formatter to the client has been checked in here: 8b0ef7f |
@maumar - Is this fixed? |
partially: the part about ignoring formatter is fixed (i.e. now we do client evaluation rather than ignoring the formatter), but what @divega was suggesting (i.e. translate some of the formatters to SQL) is not. |
We need to do analysis on formatters here. There are multiple formatters for each type, with different set of formatters on client/server side. |
@divega - Can you provide specific set of formatters which we want translated? |
@smitpatel Here is the link to the spec: Actually, I am glad that you ask because it forces me to think 😄 I believe this issue should have been closed as soon as we took @maumar's fix to switch to client evaluation rather than ignoring the formatters. We can always look into translating specific formatters to SQL based on customer data, but we don't have any at the moment. Clearing up the milestone so we can make a final decision in triage. |
Ensure that we are doing client eval. Wait for feedback before deciding to do any translation of formatters. |
We are doing client eval already. @maumar 's PR fixed it. Looks like we forgot to close the issue earlier. |
In my specific issue #10227, evaluating on the client does not resolve the issue for me |
For clarity, when and logic is applied to the where then doing this on the client is fine, but when we or the logic together with other fields you have a potential for unexpected results |
@los93sol - Client evaluation does not work by breaking into pieces without consequences. It will translate where clause appropritately & evaluate on in memory whatever cannot and always give correct results regardless of AND/OR logic. If you are having a repro code which demonstrate incorrect results for client evaluation then please file a new issue. |
Currently ToString calls with formatter (e.g ToString("X")) are translated to SQL and the formatter is ignored, we should instead translate it on the client.
The text was updated successfully, but these errors were encountered: