You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the open api specification, the behavior of the nullable property is to extend types so they also allow null if that was not the case before. From the clarification:
A true value adds "null" to the allowed type specified by the type keyword, only if type is explicitly defined within the same Schema Object. Other Schema Object constraints retain their defined behavior, and therefore may disallow the use of null as a value. A false value leaves the specified or default type unmodified. The default value is false.
This does not seem to match the behavior of the PR associated to this ticket, where we add a JsonNullable when the property is nullable.
Example:
I have a data type that is String, it is not required, therefore it can be null, so I do not need to set nullable: true. But then, because JsonNullable is not applied, I cannot differentiate when the item is omitted or is has its value explicitly set to null (exactly the same case as in this ticket.
In my understanding, the JsonNullable should be added in all non-required field, not only on nullable.
Is my understanding correct? If yes, I will make a PR to adjust that.
I agree to this explanation and want to provide further thoughts. In general we neither can assume that the server is based on this very generator nor that it is written in java so we also cannot assume it handles null on non-nullable fields as "absent". If now a non-nullable and non-required field is being sent by a generated client as null as this is at least the case with the java model classes this might be rightfully answered with bad request (400) response because it violates the api spec which did not allow null in the first place.
I have a data type that is String, it is not required, therefore it can be null
I think this is a misunderstanding. It's important to remember that OpenAPI describes JSON objects and in this context, "not required" means that the field can be missing in the JSON.
If nullable isn't specified, it's false by default, so as you said, the Java client generator will create a String field instead JsonNullable. If you want to omit it, just set it to null (the default if you don't set the field). The generator should have created an annotation for the field which instructs the serialiser to omit null fields.
When you have one of the unusual cases where null as a third option next to omission and provision of a value is needed, you would set nullable: true and the generator will use JsonNullable for the non-required field.
That's why I think everything is there, there's no actual issue and this could be closed.
Description
According to the open api specification, the behavior of the
nullable
property is to extend types so they also allownull
if that was not the case before. From the clarification:This does not seem to match the behavior of the PR associated to this ticket, where we add a
JsonNullable
when the property isnullable
.Example:
I have a data type that is String, it is not required, therefore it can be null, so I do not need to set
nullable: true
. But then, becauseJsonNullable
is not applied, I cannot differentiate when the item is omitted or is has its value explicitly set to null (exactly the same case as in this ticket.In my understanding, the
JsonNullable
should be added in all non-required field, not only onnullable
.Is my understanding correct? If yes, I will make a PR to adjust that.
openapi-generator version
4.2.2
Related issues/PRs
#1250
Suggest a fix
Apply the
JsonNullableModule
to all non-required fieldsThe text was updated successfully, but these errors were encountered: