-
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
Automatic use of ConvertChecked method when "Check arithmetic overflow" is activated in project's build settings #10955
Comments
@Vyzzuvazzadth This look like a bug - thanks for the detailed analysis! Note for fix: It looks like we are missing handling of ConvertChecked nodes in SqlTranslatingExpressionVisitor. We should review all usages of ExpressionType.Convert. |
@ajcvickers reminded me that this behavior is currently by-design because we don't want to silently remove the checking. You should be able to use Make sure you're using |
@anpete Thank you for your swift reply! It seems my mistake was to encapsulate the My assumption was that anything inside of the call stack within the
instead of
(simplified example for clarity's sake) The second example works on my end with the option Check for arithmetic overflow/underflow activated. As in no usage of I'm closing this issue since my problem has been resolved and you seem to have received enough information to look into this matter for future versions. Thanks again and have a good one! |
I think this issue should be reopened, because to use unchecked is just a workaround but not a final solution. EF 6. x also works without this workaround. |
@MarcoLoetscher @Vyzzuvazzadth I'm re-opening this so we can discuss. The question is when using overflow checking in a query, is it important that the semantics of overflow checking are preserved?
|
It would be best if I could configure the behaviour on the DbContext. |
Client evaluation is almost never a good idea. You have already made bad experiences with the missing GroupBy translation in the current EF Core version. |
I suppose I was a bit hasty with immediately closing this issue. My mistake. Anyway, @MarcoLoetscher raises some good points.
This way, we'd have full control over how EF Core behaves and also still have the option to use |
Decision from triage: we will ignore (not remove) the checked convert nodes. This means for anything evaluated on the server there will be no overflow checking, but for anything evaluated on the client it will still be used. We will stop forcing client evaluation of the query because we cannot translate a convert node. |
Run a visitor to convert convertchecked nodes to convert nodes. |
When Check for arithmetic overflow/underflow is activated in a project's build settings (Project > Properties > Build > Advanced...) Entity Framework (or the compiler?) automatically wraps some types (for example
short
) inside aConvertChecked
method call, which unfortunately has to be evaluated client-side.This causes a query with a column filter of type
short
/smallint
to retrieve much more data than necessary.We use Check for arithmetic overflow/underflow in all of our projects and we also try to accomplish as much as possible on the SQL server. To enforce that, we generally activate client evaluation exceptions for queries, which produces the following exception message when client evaluation occurs:
In the above example, the
VersionYear
field is defined assmallint
in the database and asshort
in the table model property.filter.VersionYear
(translated to the parameter__filter_VersionYear_1
) is the value the result set is to be filtered by and is also of typeshort
.Steps to reproduce
Follow the instructions for a test project here: https://docs.microsoft.com/en-us/ef/core/get-started/full-dotnet/new-db
Before adding the migration and updating the database, add a simple
short
property to theBlog
classNow finish the tutorial but don't execute the program yet.
In program.cs, replace the code within the using statement for the
BloggingContext
with the following code:Before running the program, configure the warnings for the context to throw an exception on client-side evaluation:
Now run the program. It will run through without any hiccups.
After closing the program, go to Project > Properties > Build > Advanced... and check the option Check for arithmetic overflow/underflow.
Save and run the program again.
This time, program execution will throw a
System.InvalidOperationException
sayingConvertChecked
could not be translated and will be evaluated locally.Further technical details
EF Core version: 2.0.1
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Windows 10 (1709)
IDE: Visual Studio 2017 15.5.5
Closing
Int
data types work as intended without the addedConvertChecked
method. There might be other data types with the same behavior asshort
, such asbyte
orfloat
(I unfortunately don't have time to test them all).I'm pretty sure that's by design. However, it's very unfortunate that we have to disable the Check for arithmetic overflow/underflow option to be able to sensibly enforce server-side evaluation for EF Core. Catching arithmetic overflows contributes to a better maintainability of the application, which we don't want to give up on.
EF 6.x never had that problem as we're still using that version for another project, also with the Check for arithmetic overflow/underflow option activated.
We also tried circumnavigating the
ConvertChecked
method usage by wrapping for exampleToList()
orCount()
method calls with theunchecked
keyword but to no avail.Attachments
Full test project for convenience's sake.
DBTestEFCore.zip
The text was updated successfully, but these errors were encountered: