Error messages could be better for oneOf, anyOf, allOf about ex_json_schema HOT 7 CLOSED

Yes, you're absolutely right. I did not do this for the sake of simplicity, and also because it is really challenging to interpret these kinds of errors. Especially when you're dealing with multiple levels of oneOfs and anyOfs.

I have an open branch that is addressing several open issues regarding error formats (https://github.com/jonasschmidt/ex_json_schema/tree/validation-errors). I will see if it would be easier to include this change in the scope of those changes. Unfortunately, I can't say when this will be ready for a release yet. I've had very little time to work on this project in the past months.

from ex_json_schema.

I understand there is work going on in a separate branch but is it possible to merge a short-term solution to this issue? maybe #23. In my case, there is an anyOf in the topmost level, which makes the error messages nearly useless

from ex_json_schema.

The API for the new error responses is pretty stable, the only thing missing is a formatter that takes the returned error structs and transforms them into the old {"Error message", "#/path"} tuples for backward compatibility.

I can release a 0.6.0-pre.1 version on Hex.pm and you can give it a try. Would that help you?

from ex_json_schema.

Sure, no need to make a release, I can directly test the branch. Are the changes on validation-errors branch?

from ex_json_schema.

Yes. The API changes are mostly documented in the README.

from ex_json_schema.

Thanks, so far from my testing, the errors returned are lot more informative. As it's an internal api, I am using inspect for formatting now, which is kind of OK for now. Have you thought about how to format anyOf etc?, I am not sure how it would map to a flat list of {error, path} tuple

from ex_json_schema.

The final version is released as 0.6.0 now, there are some examples in the README of how to use the error formatting.

from ex_json_schema.