Add support for symbolized keys #91

mbykovskyy · 2021-04-09T17:04:44Z

Currently, parsed JSON with symbolized key fails validation. Please add support for validating JSON with symbolized keys.

jamietanna · 2021-10-25T10:00:32Z

Have you got an example for what this trips up on?

AhmedKamal20 · 2022-01-08T21:39:06Z

Have you got an example for what this trips up on? @jamietanna

For example, Using activerecord_json_validator and passing a schema with symbolized keys like this :
validates :data, presence: false, json: { message: ->(errors) { errors }, schema: { type: :object } }
Raise this error :
JSONSchemer::InvalidSymbolKey (schemas must use string keys)

But like this
validates :data, presence: false, json: { message: ->(errors) { errors }, schema: { "type" => :object } }
Works fine

Refs:

json_schemer/lib/json_schemer/schema/base.rb

Line 49 in ab5ea07

raise InvalidSymbolKey, 'schemas must use string keys' if schema.is_a?(Hash) && !schema.empty? && !schema.first.first.is_a?(String)
Does not work with the following example #9

This uses a refinement to support indifferent access for user-provided hashes. The interface is purposefully limited to prevent future use of hash methods that may not work as expected. Refinements are tricky, though, since you lose them whenever they're out of scope (eg, passing a hash to `include?` doesn't call the refinement's `==` method). I initially tried using activesupport's `HashWithIndifferentAccess` but it doesn't work for data hashes because `insert_property_defaults` needs to operate on the actual hash. Requiring all of activesupport just for `HashWithIndifferentAccess` also felt like a pain. The refinement works slightly different from `HashWithIndifferentAccess` because it leaves the keys as whatever type they already are. That might be a little confusing in error objects and `insert_property_defaults` but at least it's consistent with whatever is passed in. Symbol keys are mostly being tested by running the json-schema-test-suite tests again with symbol keys (using `symbolize_names: true` when parsing JSON). I also pulled those tests into their own file and cleaned things up. Addresses: - #91 - #123

This deep stringifies input hashes in order to support symbol (and other non-string) keys. Symbol keys have been a common issue for people forever (as evidenced by `InvalidSymbolKey`) and I've been hesitant to address it because duplicating hashes and stringifying keys hurts performance, but I think it's probably worth it. The tricky thing here is that `insert_property_defaults`, `before_property_validation`, and `after_property_validation` need access to the actual hashes instead of the stringified version. To work around that, the original instance is passed around in `Context` and can be accessed by location using `original_instance`. Values passed in hooks need to be re-stringified in case the user added non-string keys. If this becomes a performance bottleneck, it may make sense to add a way to turn it off for people that know they're using string keys. Related: - #91 - #123

Features: - Draft 2020-12 support - Draft 2019-09 support - Output formats - Annotations - OpenAPI 3.1 schema support - OpenAPI 3.0 schema support - `insert_property_defaults` in conditional subschemas - Error messages - Non-string schema and data keys See individual commits for more details. Closes: - #27 - #44 - #55 - #91 - #94 - #116 - #123

This deep stringifies input hashes in order to support symbol (and other non-string) keys. Symbol keys have been a common issue for people forever (as evidenced by `InvalidSymbolKey`) and I've been hesitant to address it because duplicating hashes and stringifying keys hurts performance, but I think it's probably worth it. The tricky thing here is that `insert_property_defaults`, `before_property_validation`, and `after_property_validation` need access to the actual hashes instead of the stringified version. To work around that, the original instance is passed around in `Context` and can be accessed by location using `original_instance`. Values passed in hooks need to be re-stringified in case the user added non-string keys. If this becomes a performance bottleneck, it may make sense to add a way to turn it off for people that know they're using string keys. Related: - #91 - #123

Features: - Draft 2020-12 support - Draft 2019-09 support - Output formats - Annotations - OpenAPI 3.1 schema support - OpenAPI 3.0 schema support - `insert_property_defaults` in conditional subschemas - Error messages - Non-string schema and data keys - Schema bundling See individual commits for more details. Closes: - #27 - #44 - #55 - #91 - #94 - #116 - #123 - #136

This deep stringifies input hashes in order to support symbol (and other non-string) keys. Symbol keys have been a common issue for people forever (as evidenced by `InvalidSymbolKey`) and I've been hesitant to address it because duplicating hashes and stringifying keys hurts performance, but I think it's probably worth it. The tricky thing here is that `insert_property_defaults`, `before_property_validation`, and `after_property_validation` need access to the actual hashes instead of the stringified version. To work around that, the original instance is passed around in `Context` and can be accessed by location using `original_instance`. Values passed in hooks need to be re-stringified in case the user added non-string keys. If this becomes a performance bottleneck, it may make sense to add a way to turn it off for people that know they're using string keys. Related: - #91 - #123

Features: - Draft 2020-12 support - Draft 2019-09 support - Output formats - Annotations - OpenAPI 3.1 schema support - OpenAPI 3.0 schema support - `insert_property_defaults` in conditional subschemas - Error messages - Non-string schema and data keys - Schema bundling See individual commits for more details. Closes: - #27 - #44 - #55 - #91 - #94 - #116 - #123 - #136

davishmcclurg · 2023-08-20T21:03:44Z

Released in 2.0.0. Schema keys are deep-stringified to support symbols.

Note: symbol values are not supported (eg, type: :object above).

ahx mentioned this issue Feb 14, 2022

Populate default parameter values ahx/openapi_first#126

Merged

davishmcclurg mentioned this issue Aug 1, 2023

2.0.0 #135

Merged

davishmcclurg closed this as completed Aug 20, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for symbolized keys #91

Add support for symbolized keys #91

mbykovskyy commented Apr 9, 2021

jamietanna commented Oct 25, 2021

AhmedKamal20 commented Jan 8, 2022 •

edited

Loading

davishmcclurg commented Aug 20, 2023

Add support for symbolized keys #91

Add support for symbolized keys #91

Comments

mbykovskyy commented Apr 9, 2021

jamietanna commented Oct 25, 2021

AhmedKamal20 commented Jan 8, 2022 • edited Loading

davishmcclurg commented Aug 20, 2023

AhmedKamal20 commented Jan 8, 2022 •

edited

Loading