You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider the schema {"oneOf": [{"required": ["foo"]}, {"required": ["bar"]}]}
What values could match this? Because the two sub-schemas only constrain objects, all values of any other type will be valid against both sub-schemas... and therefore invalid against the oneOf schema.
Obviously it would be nicer to support such schemas properly, by canonicalising them to include type: object (i.e. exclude other types) and therefore translate them to a Hypothesis strategy which doesn't have to filter out so much.
The semantics are a bit too tricky for me to tag this good first issue, though the tests will catch any plausible mistakes you could make. We have some prior art in the handling of "not" sub-schemas, which might provide a good starting point; you might even move shared logic to a new helper function.
Alternatively, 'lowering' oneOf: [a, b, c] to anyOf: [{**a, not: {anyOf: [b, c]}}, ...] would automatically share any improvements to not-logic, which would be nice. Just a question of balancing that against the less elegant canonical form.
The text was updated successfully, but these errors were encountered:
I'm now convinced that 'lowering' is the way to go, along with associated improvements to canonicalising anyOf lists (e.g. de-nesting them, taking unions of schemas, etc.) and special handling for not: anyOf: ... patterns. Fortunately these are independently useful changes, though obviously complementary!
Consider the schema
{"oneOf": [{"required": ["foo"]}, {"required": ["bar"]}]}
What values could match this? Because the two sub-schemas only constrain objects, all values of any other type will be valid against both sub-schemas... and therefore invalid against the
oneOf
schema.This tends to result in a lot of filtering, so we have a workaround in our tests for this test case.
Obviously it would be nicer to support such schemas properly, by canonicalising them to include
type: object
(i.e. exclude other types) and therefore translate them to a Hypothesis strategy which doesn't have to filter out so much.The semantics are a bit too tricky for me to tag this
good first issue
, though the tests will catch any plausible mistakes you could make. We have some prior art in the handling of"not"
sub-schemas, which might provide a good starting point; you might even move shared logic to a new helper function.Alternatively, 'lowering'
oneOf: [a, b, c]
toanyOf: [{**a, not: {anyOf: [b, c]}}, ...]
would automatically share any improvements tonot
-logic, which would be nice. Just a question of balancing that against the less elegant canonical form.The text was updated successfully, but these errors were encountered: