Closed jfacorro closed 4 years ago
Since we now have 2 versions to choose, I think it's generally better to present more information to the user and let them decide what to do with it. The only potential issue is that the error report for big nested *Of
schemas risks to be really huge, because each sub-error includes their part of the schema. It can explode receiver process heap size if sent to another process (eg, logger) or written to ETS or sent via distribution.
I think we can merge this PR and disregard #91 for now. Maybe adding an option to tune *Of
error reporting in the follow-ups.
Any opinions? @andreineculau maybe?
Thanks! I think the explanation about anyOf
makes sense and we can add allOf
later if someone asks.
This PR is an alternative to the approach taken in PR #91.
The difference is that in this PR, when a
oneOf
validation fails, the returned errors include all of the validation errors from each schema in the list of theoneOf
schema.