Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Symbol keys are not supported in objects within arrays #104

Closed
jamiecobbett opened this issue Jul 15, 2014 · 0 comments · Fixed by #105
Closed

Symbol keys are not supported in objects within arrays #104

jamiecobbett opened this issue Jul 15, 2014 · 0 comments · Fixed by #105

Comments

@jamiecobbett
Copy link
Contributor

If you supply a data object which contains an array of objects with symbol keys, they are treated as being absent.

require 'json-schema'

schema = {
  "type" => 'object',
  "properties" => {
    "a" => {
      "type" => "array",
      "items" => {
        "properties" => {
          "awesomeness" => {
            "type" => "integer"
          }
        }
      }
    }
  }
}

data = {
  a: [
    {
      awesomeness: 1
    }
  ]
}

errors = JSON::Validator.fully_validate(schema, data)
if errors.any?
  puts 'Invalid:'
  p errors
else
  puts 'Valid'
end

This returns:

["The property '#/a/0/awesomeness' of type NilClass did not match the following type: integer in schema f092eaf2-bbef-50c6-8955-9cc93e53bbb6#"]

I believe this is the same bug as #101 and #94.

There were changes last year to address equivalent problems: 0146e33. The fix isn't obvious to us, but we are happy to provide a fix with test given a pointer to the problem.

jennyd added a commit to jennyd/json-schema that referenced this issue Jul 15, 2014
JSON::Schema.add_indifferent_access was only able to recurse into
hashes directly contained within another hash; as soon as it found a
value which was not a hash it stopped. This meant that hashes within
arrays were not being made indifferent to the key type, and so data
which included symbol keys in a hash in an array were failing validation
against a JSON schema when they should have been valid.

This commit adds a failing minimal test for this case and fixes voxpupuli#104.
We think that voxpupuli#104 is a duplicate of voxpupuli#101 and voxpupuli#94 so those issues are
likely to be fixed by this as well.
jennyd added a commit to jennyd/json-schema that referenced this issue Jul 16, 2014
JSON::Schema.add_indifferent_access was only able to recurse into
hashes directly contained within another hash; as soon as it found a
value which was not a hash it stopped. This meant that hashes within
arrays were not being made indifferent to the key type, and so data
which included symbol keys in a hash in an array were failing validation
against a JSON schema when they should have been valid.

This commit adds a failing minimal test for this case and fixes voxpupuli#104.
We think that voxpupuli#104 is a duplicate of voxpupuli#101 and voxpupuli#94 so those issues are
likely to be fixed by this as well.
jennyd added a commit to jennyd/json-schema that referenced this issue Jul 16, 2014
JSON::Schema.add_indifferent_access was only able to recurse into
hashes directly contained within another hash; as soon as it found a
value which was not a hash it stopped. This meant that hashes within
arrays were not being made indifferent to the key type, and so data
with symbol keys in a hash in an array were failing validation when
they should have been valid.

This commit adds a failing minimal test for this case and fixes voxpupuli#104.
We think that voxpupuli#104 is a duplicate of voxpupuli#101 and voxpupuli#94 so those issues are
likely to be fixed by this as well.
jennyd added a commit to jennyd/json-schema that referenced this issue Jul 16, 2014
JSON::Schema.add_indifferent_access was only able to recurse into
hashes directly contained within another hash; as soon as it found a
value which was not a hash it stopped. This meant that hashes within
arrays were not being made indifferent to the key type, and so data
with symbol keys in a hash in an array were failing validation when
they should have been valid.

This commit adds a minimal test for this case and fixes voxpupuli#104.
We think that voxpupuli#104 is a duplicate of voxpupuli#101 and voxpupuli#94 so those issues are
likely to be fixed by this as well.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant