openapi-generator
openapi-generator copied to clipboard
[dart-dio] Required fields are serialized if they are nullable. Non-required fields are skipped.
If a property is nullable, there can be a great difference if a value is null or not present. Without the serialization of null, a nullable field can not be set to null, if the api assumes that fields which are not present are left as they are.
PR checklist
- [x] Read the contribution guidelines.
- [x] Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
- [x] Run the following to build the project and update samples:
Commit all changed files. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example./mvnw clean package ./bin/generate-samples.sh ./bin/utils/export_docs_generators.sh./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH. - [x] File the PR against the correct branch:
master(6.1.0) (minor release - breaking changes with fallbacks),7.0.x(breaking changes without fallbacks) - [x] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.
@jaumard @josh-burton @amondnet @sbu-WBT @kuhnroyal @agilob @ahmednfwela
Please fill out the whole PR template and mention the tech committee for the appropriate language/generator. Otherwise this PR just gets lost.
Only required fields are serialized when they are nullable. Non-required fields are skipped.
@kuhnroyal thanks for the feedback. Tried to do my best, please let me know if it is better now, or what needs further adjustment. Thanks
I don't think this will work, this does now exactly the same thing as a required property.
We don't have a way in Dart to distinguish null from uninitialized, unless we introduce some kind of value type for all fields.
But with the current situation, one is not able, to set a nullable property null if it is not required because it just doesn't get serialized.
As an example: if an endpoint gets extended by a nullable not required property, it has to presume that if the property value is not set, it stays untouched. This has to be like this to prevent breaking an older client, but if now a new client wants to set the newly added property to null, it is not possible to do so in the current situation.
For this reason, I think such a null value should be serialized as null because the swagger definition clearly states that it can be null.