processing validation errors raises if a key happens to be an integer about json_schemer HOT 3 CLOSED

That's tricky. There was a similar issue with symbol keys causing issues as well. It might be worth validating that all the schema keys are strings. Another option would be allowing schemas to validate themselves against their meta-schema. I was hoping to not have to do that because of how it would impact performance, but I should test how much overhead it actually causes.

Can I ask how you're using the library? You should be able to introduce something like deep_stringify_keys before passing the schema hash in to get things working how you expect.

from json_schemer.

Can I ask how you're using the library?

We have a tool that lints our OpenAPI spec files and the very first thing it does is to validate the OpenAPI against the schema.
Right now we're using json-schema and it doesn't seem to care about such integer keys, for right or wrong.

I'd rather not having to do any processing to the schema we pass to validate and leave that to the library. Errors are expected and I guess it wouldn't be out of place for json_schemer to raise on such cases. The only thing then is it should raise proper errors so we can rescue them properly.
If not raising is desirable then internally it should rescue everything and return an error without blowing up. I don't know if it's by design but for instance if I pass nil or an empty string right now it doesn't raise.

from json_schemer.

Allow me to close this issue, we figured that we're talking about json schema and by definition the keys are string so this is something we need to handle when processing our input YAML files so they behave the same as JSON files (which is also a valid OpenAPI format).
Thanks!

from json_schemer.