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

Canonicalise oneOf sub-schemas to exclude shared types #40

Open
Zac-HD opened this issue May 16, 2020 · 1 comment
Open

Canonicalise oneOf sub-schemas to exclude shared types #40

Zac-HD opened this issue May 16, 2020 · 1 comment

Comments

@Zac-HD
Copy link
Member

Zac-HD commented May 16, 2020

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] 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.

@Zac-HD
Copy link
Member Author

Zac-HD commented Jul 1, 2020

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!

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

1 participant