-
-
Notifications
You must be signed in to change notification settings - Fork 593
Add a deprecation warning to validate_for if schema doesn't exist #484
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
Add a deprecation warning to validate_for if schema doesn't exist #484
Conversation
Codecov Report
@@ Coverage Diff @@
## master #484 +/- ##
==========================================
+ Coverage 94.88% 94.91% +0.02%
==========================================
Files 19 19
Lines 2309 2320 +11
Branches 300 301 +1
==========================================
+ Hits 2191 2202 +11
Misses 104 104
Partials 14 14 |
Awesome! Well done. Will leave some notes but pretty sure this is exactly what I was after here.
|
jsonschema/tests/test_validators.py
Outdated
category=DeprecationWarning, | ||
message=( | ||
"This schema was not found but going to validate with latest draft. " | ||
"This will raise a SchemaError in future. " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I don't think I love this becoming a SchemaError
, I think SchemaError
is more specific (than its name), and we use it for just the equivalent of meta schema validation.
Here it's more likely we should just define a CannotLocateMetaschema
exception for this specific case.
But, even better than committing right now to a specific thing would just be to say "it will raise an error.", and leave it unspecified.
And if we can, maybe reword the first sentence here to something more like "This schema defines a $schema property for an unregistered or unknown meta-schema. This will raise an error in the future. Register a validator for use with this $schema by calling jsonschema.validates."
Sound reasonable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What schema are you referring to by this schema
in "This schema defines a $schema property for an unregistered or unknown meta-schema ... "
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The one that was passed into either validator_for
or transitively validates
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed the other comments. Good point about leaving it unspecified. And about the schema - you mean whatever is the value of this schema.get(u"$schema", u"")
. I believe I get it now, but shouldn't we add the name of the schema we are saying is unregistered to the warning message?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Literally in that line schema
:)
The thing that contains the $schema
.
This situation we're deprecating basically happens when someone says
validator_for({"$schema", "foobarbaz", ...})
or validate(someinstance, {"$schema", "foobarbaz", ...})
, where foobarbaz is supposedly the metaschema for that schema, but didn't tell jsonschema
which validator should be used to validate schemas that use that.
Which actually I believe points out a bug in the implementation here.
You're calling schema.get("$schema", "")
and warning any time that the resulting $schema
isn't registered, but that will warn even in the case where $schema
isn't present. Doing that isn't wise, but isn't per se part of what we need to deprecate here. The thing we're deprecating here is the behavior that takes a schema like {"$schema": "unknown"}
and silently still uses a validator for that, rather than saying "I don't know what meta schema unknown
refers to, so I can't pick a Validator class for it".
Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what should happen in this case that the schema doesn't exist? - use the default draft? nice catch by the way (the bug, when $schema
doesn't exist
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep exactly, this is the case the default
argument is designed for -- so, we should likely add a test that this case doesn't warn.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going to have to do that tomorrow.. it's midnight here and work tomorrow.
jsonschema/tests/test_validators.py
Outdated
|
||
f=validators.validator_for, | ||
schema={}, | ||
default={} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a trailing comma here? (Not sure why ebb-lint didn't complain it was missing)
I'd be remiss also not to lament every time this comes up that the warnings module is crippled and terrible :( (because it hides |
@Julian updated the pr please take a look |
jsonschema/tests/test_validators.py
Outdated
self.assertWarns( | ||
category=DeprecationWarning, | ||
message=( | ||
"This schema was not found but going to validate with latest draft. " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This error message still confuses me. What is it you're referring to here by "schema"? It's not a schema that wasn't found here really.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are correct, its the metaschema that's missing
Fixed the failing test on merge. Really appreciated! |
0aefbb3d Merge pull request #491 from jdesrosiers/object-contains-tests 336ef8d2 Merge pull request #452 from LeifRilbe/rilbe/propertyNames-with-pattern 2dfbc79c Simplify the test case names as well. b6d0649d Add tests for contains with objects da687ca5 Enforce a consistent code style for contains tests b163efcf Merge pull request #490 from jdesrosiers/draft-future 7c8cb488 Initialize draft-future with 2020-12 tests 4d65d2df Merge pull request #483 from kylef/kylef/date ee9dcaa7 Merge pull request #485 from marksparkza/contains-with-false-if eaa5bffc Merge pull request #489 from json-schema-org/ether/more-recursiveRef 7c33b533 dynamic $recursiveRef test with cousin $recursiveAnchors 8a3a542b Fix invalid JSON error 8a89f58e Add tests combining remote refs and defs 3aec0d14 Add tests combining relative refs and defs a107d196 fix: $defs -> definitions in draft 6,7 tests 0c223de2 Remove a test for undefined $id behavior 4efec180 Test that "contains" does not fail due to false "if" subschema bf383b4c fix: make identifiers unique across tests 812f1f08 Merge pull request #484 from json-schema-org/ether/schemas-under-unknown-keywords 64f6b850 Test that identifiers are not found inside unrecognized keywords c69a89c6 Stricter date format constraints 93193442 Test cases for propertyNames with pattern - update after PR feedback. 8e4aad95 Test cases for propertyNames with pattern. git-subtree-dir: json git-subtree-split: 0aefbb3d80e0caa22f3782677cf09c61b2205aa7
This addresses this issue #460
Followed your lead by using the
SynchronousTestCase
. Any reason or particular features that drive using it instead of justTestCase
?Please let me know if you have any comments. Can't think of any other bright ideas regarding the warnings. First time using the module :) and feels like a pretty small PR so maybe I am missing something.