Closed didier-brizet closed 10 months ago
I propose the following patch:
@pboettch We have the same issue with a complex schema, is there anything that still needs to be done in the PR before it can be merged?
It's a huge change. Hard to review. Especially if you're not convinced of the handling of default values inside the validator.
I'd rather prefer to have an outside-of-the-validator solution of default-value-handling. But this is off-topic for this PR.
Hm I'm not sure if this applies here, the patch is intended to be a way to make the invalid json valid again, so the patch
[{"op":"add","path":"/code","value":2}]
would really be the only valid solution, or am I missing something here?
With a patch like the one that is currently returned
[
{"op": "add", "path": "/code", "value": 1},
{"op": "add", "path": "/code", "value": 2}
]
there are two main problems from my perspective:
{"op": "add", "path": "/code", "value": 1}
doesn't result in a valid json (it doesn't match with any of the oneOf schemas)Any updates on this issue? Especially, is there something blocking #231 from being merged?
I won't accept big changes anymore on patch creation concerning default values. I'm not convinced that this library is the right place. Or at least it should not be integrated in the code as it is today.
Only the default value of one of "oneOf" sub-schema must be inserted in patch returned by
json_validator::validate
.For instance, the validation of
{"name": "bar"}
against the following JSON schema:must returns the patch
[{"op":"add","path":"/code","value":2}]
but the following patch is returned:[{"op":"add","path":"/code","value":1},{"op":"add","path":"/code","value":2}]