Closed hellnn closed 1 year ago
I would expect it works like that by default?
Technically when its missing it should be the value assigned in the ctor. So if its null in ctor it should remain null. If its empty in ctor it should remain empty
The problem is, if you use the java validation api, then the @NotNull annotation works only for null fields, so you cannot validate bean required fields and for example Jackson deserializes missing fields as null by default
I'm not sure I understand what you mean by validating them.
If you want to force having this field in JSON, you can do that by turning mandatory on for this field. It can still be null even when mandatory. Mandatory means it must be present in the JSON. That way you can validate it and force it to be expected in JSON.
If your class does not have empty ctor and instead expects all properties during construction, it will use default value for this type (unless you override it) which in this case is null. So if its missing then it will be null.
If your class has empty ctor then it will leave this field alone unless its specified in the JSON. This way you can setup default values for your fields in your ctor.
So the behavior you want is possible and unless you initialized that property in ctor to empty instance I would expect it already behaves like that. Is that not whats going on?
Leaving the field as is, instead of setting it to null when its missing in JSON seems to me like much better default behavior.
You can take a look at this test: https://github.com/ngs-doo/dsl-json/commit/c7f6d145b7c8aaca1232b35959aef7fe4fd3c750
It shows explicit expected behavior of DSL-JSON. If field is non-nullable, but DSL-JSON detects that its still null after deserialization it will assign default value for it. For strings that is empty string, for references this is instance from empty ctor.
Ok, There is using @JsonAttribute, but in my case this annotation not use, because classes are generated by OpenApi generator, I think the default behavior should be for fields as nullable true if annotation is absent
NonNull annotation should behave the same as nullable=false in JsonAnnotation
Anyway... its hard to me to understand the problem you are having. I suggest making a PR with a test in which you show the behavior and expected result.
I am expecting that the default behavior for @NotNull should be as nullable=true, otherwise, the bean validation does not work, because the field will always be not null
The default behavior of DSL-JSON is to throw validation exception for null values on properties marked with NotNull. It seems wrong that it behaves any different than this by default. This ones are recognized by default: https://github.com/ngs-doo/dsl-json/blob/master/java8/src/main/java/com/dslplatform/json/processor/CompiledJsonAnnotationProcessor.java#L67
Actually what do you mean nullable = true for NotNull You want DSL-JSON to ignore nullable annotation and let the property through so you can do your own validation?
It seems what you want is being able to configure the list of signatures in those lookups. That seems fair, but its not currently supported out of the box.
To get that behavior you will have to copy this annotation processor class and remove the signatures from there.
Yes, there is java validation api, that generates errors when validating beans
Ok, I'll keep this in mind when releasing next version. But I don't think that will be soon.
Thank you, I've found a workaround for my case so far
There is now new option to specify this behavior: https://github.com/ngs-doo/dsl-json/commit/c6b790e8cb3446fc53fee17e04c647b7fb2f0001
v1.10 released
Is it possible to deserialize missing nested objects to null reference, rather than empty objects?
For example:
{name: ''foo"}
class Event { private String name; private Source source } class Source { private String name }
In this case after deserialization event source field should be null