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

Schema Validation - Capitals and nested JSON #15

Open
drasko opened this issue May 24, 2016 · 1 comment
Open

Schema Validation - Capitals and nested JSON #15

drasko opened this issue May 24, 2016 · 1 comment
Assignees

Comments

@drasko
Copy link

drasko commented May 24, 2016

In relation to: litixsoft/lx-mongodb#1 (comment)

I did further tests and I noticed:

  1. Capitals are not respected for nested JSON fields, weather they are required or not
  2. I have put all 3 fields of location to be required (here: https://github.com/litixsoft/lx-valid/blob/master/test/revalidator.spec.js#L967-L984), and I was still capable to pass just some of them (one or two of them, but not whole 3), and that would be validated as true. This is obviously wrong.

So, it seems that for the nested field not only that capital letter check does not work, but schema check does not work neither! I.e. we are capable to pass incomplete JSON, and that would validate as true.

@4kochi
Copy link
Collaborator

4kochi commented May 29, 2016

I have pushed a new branch '#15' including a new unit test for your case. All fields of Location are required. This is what the test is checking for and it passes. So feel free to change the test so that it will fail and I can reproduce the problem.

Regarding the Capitals there is one option in lx-valid which will be interesting for you. By default the option additionalProperties is set to true which means the data could contain fields which are not part go the schema and the validation won't fail. An example would be if your field is names location instead of Location. Then it would not use the schema for the field Location, because the validator is case sensitive. And since there is no schema for location and additionalProperties is true there will be no error. If you set additionalProperties to false, then there will be a validation error.

You can also use the option unknownProperties to control how additional data, which is not in the schema, should be handled.

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

No branches or pull requests

2 participants