-
Notifications
You must be signed in to change notification settings - Fork 17
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
isSubschema returns false on added, but not required properties? #14
Comments
Hi, thanks for your question! In your example, s2 is a subschema of s1, because every JSON document that is valid for s2 is also valid for s1. However, s1 is not a subschema for s2. Here is a counter-example: j0 = {
"error_message": "aarrr",
"not_required_field": 42,
}
def valid(instance, schema):
try:
jsonschema.validate(instance, schema)
except jsonschema.ValidationError as e:
return f"False: {e}"
return True
print(f"valid(j0, s1) {valid(j0, s1)}")
print(f"valid(j0, s2) {valid(j0, s2)}") That code will print the following:
In other words, j0 is valid for s1 but not for s2, because s1 ignores the integer field, whereas s2 requires it to be a string. |
I see - that makes sense, in that it matches the logical constraints defined 👍 I will probably need to fork this and add a more "relaxed" mode in the sense that for verifying breaking changes (in a CLI, for instance), I'm not particularly interested on whether ignored fields in Interesting alteration though is that the error is still returned if I don't define a
In this case, no matter the type that is passed to |
Thank you both for your question(s) and answer! For the second comment, @JCachada, you are right. What you see is wrong behavior. I checked it and I confirm what you observed. Regards, |
PR #16 has been merged, and is included in the newest release (https://github.com/IBM/jsonsubschema/releases/tag/v0.0.7), which has also been pushed to pypi (https://pypi.org/project/jsonsubschema/0.0.7/) |
Hello!
I'm seeing some odd behavior and I'm wondering if I'm missing something obvious.
Let's say I have a
JSONSchema
object like such:And I add a property that is not required, like such:
My expectation in regards to breaking change compatibility is that this would not be considered a breaking change - that is, that
isSubschema
would return "True" when checkings1,s2
, seeing as bodies that are valid for the first schema will still be valid for the second schema. Making them invalid would require adding anot_required_field
to therequired
array in the second schema. Without that, the first schema should be a valid subschema of the second schema.However, comparing these two schemas makes
isSubschema
returnFalse
.I have looked through the attached paper and seen:
Seeing as this is not a union or a negated schema, I would think that this would be a supported use case.
Am I missing something obvious? I did try to run through my debugger through the lib but to no great success.
I appreciate the help (and the work on the lib)!
Best
The text was updated successfully, but these errors were encountered: