-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Use the declared type to infer NullableContextOptions #15134
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
Conversation
Prior to this change MVC used the runtime type rather than the declared type to determine the nullability of a property based on state. In the case of inheritance, this can be erroneous since the declared type may have a different nullability context than the model type. This change addresses this by adding content to `ModelIdentity` that allows inspecting the declared type. * Add an overload to `ModelMetadataIdentity` that allows flowing `PropertyInfo` * Use the declared type in `DataAnnotationsMetadataProvider` to determine nullability based on context. Fixes #14812
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mostly have dumb questions. Signing off since you know better 😉
src/Mvc/Mvc.DataAnnotations/test/DataAnnotationsMetadataProviderTest.cs
Outdated
Show resolved
Hide resolved
|
||
if (HasNullableAttribute(context.PropertyAttributes, out var propertyHasNullableAttribute)) | ||
{ | ||
addInferredRequiredAttribute = propertyHasNullableAttribute; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, i'm confused, so if it has the nullable attribute then we DO add the required attribute? Isn't that backwards? I'm sure it's just me misunderstanding the code since your mass amount of tests show differently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might help: https://github.com/dotnet/roslyn/blob/master/docs/features/nullable-metadata.md#type-parameters, but essentially non-null
is represented as [Nullable(1)]
. HasNullableAttribute
returns true
if the attribute is present, the propertyHasNullableAttribute
says if the value is 1
.
else | ||
{ | ||
addInferredRequiredAttribute = IsNullableReferenceType( | ||
property.DeclaringType, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And just to clarify, this is the key piece that makes the customers scenario work correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, one last question when a user shadows a nullable property are there two model identitys? Aka, one for each property?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And just to clarify, this is the key piece that makes the customers scenario work correct?
Yeah. Well more like fixes our bug
Also, one last question when a user shadows a nullable property are there two model identitys? Aka, one for each property?
Yup. Although our property discovery will skip over shadowed properties: https://github.com/aspnet/AspNetCore/blob/master/src/Shared/PropertyHelper/PropertyHelper.cs#L441-L477
src/Mvc/Mvc.Abstractions/src/ModelBinding/Metadata/ModelMetadataIdentity.cs
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My main concern here is about the breaking change. Can we use a flag to avoid making a breaking change?
src/Mvc/Mvc.Abstractions/src/ModelBinding/Metadata/ModelMetadataIdentity.cs
Show resolved
Hide resolved
…erTest.cs Co-Authored-By: N. Taylor Mullen <[email protected]>
Prior to this change MVC used the runtime type rather than the declared type to
determine the nullability of a property based on state. In the case of inheritance,
this can be erroneous since the declared type may have a different nullability context
than the model type.
This change addresses this by adding content to
ModelIdentity
that allows inspecting thedeclared type.
ModelMetadataIdentity
that allows flowingPropertyInfo
DataAnnotationsMetadataProvider
to determine nullability based on context.Fixes #14812