Closed gwesterman closed 1 year ago
This @DtoUpdateHidden
has nowhere been in the code. That's why it has no effect. I didn't noticed it yet in the readme so far.
Is this a feature you actually need? Basically a partial @DtoReadOnly
?
Yes, exactly, a partial @DtoReadOnly
for create and update that restricts the user from updating values that should only be set once when creating a data entry and vice versa.
At first I thought this would only be a nice-to-have but there's real value to this. If I could rely on the API validation to immediately throw an error if the transferred object contains fields that are not whitelisted, I can simply save any data that is successfully validated based on rules set in the schema file. Otherwise I would have to manually map the DTO to an object that only contains fields I know can be updated instead of simply relying on my schema.
This adds a second validation layer, creating additional code that has to be maintained and could cause issues such as additional fields that are added later being stripped by mapping logic that wasn't updated for example.
There should only be a single source of truth, in this case the schema file.
With v1.18.0-beta1 release, I also added @DtoCreateHidden
and @DtoUpdateHidden
annotations.
I've been testing this with v1.18.0-beta2 and it works like a charm, thanks!
The README mentions the following annotation:
Using
@DtoUpdateHidden
in my own model has no effect on the UpdateDTO, which still shows the field as optional.I would expect the field to be omitted from the UpdateDTO while still being available in the CreateDTO and Entity.
Currently I can not rely on my API validation to remove this value on a request level using white listing rules.