I've noticed that when a schema has a list of possible types and the data doesn't match any of them, the error message is not terribly helpful -- it just says that the value doesn't match the schema and leaves it to the user to figure out why.
An example:
Value {'a': 1} for field '_data' doesn't match any of 2 subtypes in [{'type': 'object', 'properties': {'a': {'type': 'integer'}, 'b': {'type': 'integer'}}}, {'type': 'object', 'properties': {'a': {'type': 'integer'}, 'c': {'type': 'integer'}}}]
This is hard to read, because long JSON schemas that are not indented are hard to read (for me at least). It also doesn't tell you that the problem is that b or c is missing -- the user has to inspect the schema themselves to determine this.
If we indent the schema, it's a little easier to see what's going on, although the user still has to inspect it to see that b or c is missing.
Value {'a': 1} for field '_data' is not of type
[
{'type': 'object', 'properties': {'a': {'type': 'integer'}, 'b': {'type': 'integer'}}},
{'type': 'object', 'properties': {'a': {'type': 'integer'}, 'c': {'type': 'integer'}}}
]
This is from https://gist.github.com/msabramo/4963773; which is a small test program that illustrates that the error messages are very useful when matching against a single type, but not so useful when matching against a list of types.
I am not sure exactly of how to provide a message that is useful and succint -- this is kind of hard because it's difficult for validictory to know which type the data is closest to. One idea is to have the error message include a list of all of the validation errors for each of the "sub types" -- I will be sending a PR soon that illustrates this approach.
I've noticed that when a schema has a list of possible types and the data doesn't match any of them, the error message is not terribly helpful -- it just says that the value doesn't match the schema and leaves it to the user to figure out why.
An example:
This is hard to read, because long JSON schemas that are not indented are hard to read (for me at least). It also doesn't tell you that the problem is that
borcis missing -- the user has to inspect the schema themselves to determine this.If we indent the schema, it's a little easier to see what's going on, although the user still has to inspect it to see that
borcis missing.This is from https://gist.github.com/msabramo/4963773; which is a small test program that illustrates that the error messages are very useful when matching against a single type, but not so useful when matching against a list of types.
I am not sure exactly of how to provide a message that is useful and succint -- this is kind of hard because it's difficult for validictory to know which type the data is closest to. One idea is to have the error message include a list of all of the validation errors for each of the "sub types" -- I will be sending a PR soon that illustrates this approach.