-
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
Exception when loading entity containing a primitive property with matching System.Nullable backing field #12215
Comments
@KSid It's surprising that this worked in 2.0. Having a property that returns a different value than it was set to will often result in issues. For example, using this pattern, how do you ensure that -1 is not saved to the database? That being said, this does look like a bug generating the query. |
Thanks for taking a look, @ajcvickers. I have done a little more digging and found the exception is only thrown when using QueryTrackingBehavior.NoTracking and affects the new 'query types' feature regardless of this setting. It can be also reproduced without involving the database as the exception is thrown before EF attempts a connection. Fortunately the affected class is readonly and interfaces with a third party database so I've not needed to test how it behaves when updating the field and saving the changes. If it became a requirement and we wanted to keep storing nulls instead of -1, I suspect we would have to hard code the backing fields as magic strings in the model mapping or use a leaky model by exposing the int? directly alongside an additional unmapped property just to be used by the application code. A cleaner, less magical option would probably be to take advantage of the new conversion features if they are updated in the future to support primitive to primitive? conversions. |
Thank you for assigning some time to this, @ajcvickers. Is the 2.2 milestone an estimate? I was hoping the regression could be fixed and released as part of a 2.1.x release. |
@KSid There is some possibility this could get patched, but right now it's just above the patch bar. Things that could change this are:
|
Error in 3.1
@ajcvickers - Can you give this a read and see if this is expected? |
@smitpatel I still wouldn't expect this to work, and the exception is certainly linked to the way the property is mapped. Will look at this while working on #15182. |
Took another look at this in relation to #15182. That change allows a nullable backing field to be used for a non-nullable property. However, there are two additional behaviors here. The first is to allow the column to be created in the database as nullable, even though it is non-nullable in C-space. This is can be done by editing the generated migration, although its's a strange thing to do, since nulls from the database would not be able to be used. However, the second behavior is an apparent desire to replace nulls with -1, at least when null is supplied by the client, and possibly when it comes from the database. This then falls under the value conversions to and from null, tracked by #13850. |
Using EF Core 2.1 throws an exception when loading entities that have mapped properties with primitive types that have matching System.Nullable backing fields of the same type (e.g. int property with int? backing field). This has been working without problem on previous releases of EF Core (1.1.x - 2.0.x).
P.S. Is there an alternative approach available that avoids hardcoding the name of the backing field during model mapping? It doesn't look like the new conversion facilities will work here due to the (current) inability to convert null.
Steps to reproduce
Further technical details
EF Core version: 2.1.0
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Windows 10 Version 1803
IDE: Visual Studio 2017 15.7.3
The text was updated successfully, but these errors were encountered: