In a number of cases, our NJsonSchema-generated classes reflected an unintentional strange state: that of being required but possibly null. This is rarely practically useful: in nearly all cases we want a property to either be required or to permit null, but not both.
DESCRIPTION:
Adapts all usage of the Required.AllowNull attribute to be either Required.Always, or not required. Since these values could always be null anyway, the code is generally able to tolerate their "nullness" — the difference is just whether or not we get a serialization failure if a null is omitted from the json. For example:
{
Perimeter: [...],
Voids: null
}
is a valid Profile, but
{
Perimeter: [...],
}
will throw a deserialization error, even though the code can handle it.
BACKGROUND:
required
but possiblynull
. This is rarely practically useful: in nearly all cases we want a property to either be required or to permit null, but not both.DESCRIPTION:
Required.AllowNull
attribute to be eitherRequired.Always
, or not required. Since these values could always be null anyway, the code is generally able to tolerate their "nullness" — the difference is just whether or not we get a serialization failure if anull
is omitted from the json. For example:is a valid
Profile
, butwill throw a deserialization error, even though the code can handle it.
TESTING:
This change is![Reviewable](https://reviewable.io/review_button.svg)