Support for 'readyOnly'

[evert]

What version of Ajv you are you using?

8.4.0

What problem do you want to solve?

json-schema has a readOnly property. This is super handy because a really common use-case is for json-schema to describe an entity (lets say 'an article') and that schema to be re-used for both GET and PUT requests.

But if that schema has an id field, you kinda want to omit that on PUT. A different option to handle this is to have 2 schemas, or make id non-required, but the former is a pain to maintain, and the latter makes it somewhat inaccurate.

The readOnly annotation captures this use-case really well, so if there's a way we can tell Ajv: validate, but use the 'readOnly' case, it should remove those properties before validating.

What do you think is the correct solution to problem?

Not familiar enough with Ajv internals

Will you be able to implement it?

Unlikely =(

[stellarhoof]

Related issue: #909

[epoberezkin]

The readOnly annotation captures this use-case really well, so if there's a way we can tell Ajv: validate, but use the 'readOnly' case, it should remove those properties before validating.

Why would readOnly properties be excluded from validation? It might make sense to exclude these properties from any changes.

[Morriz]

Why would readOnly properties be excluded from validation? It might make sense to exclude these properties from any changes.

Does this mean you would consider giving this request attention? I see the need to honor readOnly fields go back years, but seems to always have been downplayed. Too bad no PR has landed to solve this. Is it too hard to do? I have not looked at the underlying code.

[Morriz]

I see jsonschema's definition of readOnly as not requiring to deny such field values on mutating requests ("attempts by an application to modify the value of this property are expected to be ignored or rejected by that owning authority", emphasis on ignored).

Now, if AJV decides to intervene in these matters ("reject" as opposed to "ignore"), then it takes on the responsibility of offering an escape hatch for such (flexibility is key).

If, to stay out of this altogether, it could "ignore" them, and let the underlying layer strip readOnly fields or check to see if those are changed.