fix: anyOf compare alternatives#1037
fix: anyOf compare alternatives#1037msivasubramaniaan merged 5 commits intoredhat-developer:mainfrom
Conversation
| let enumValueMatch = false; | ||
| for (const e of schema.enum) { | ||
| if (equals(val, e) || (callFromAutoComplete && isString(val) && isString(e) && val && e.startsWith(val))) { | ||
| if (equals(val, e) || isAutoCompleteEqualMaybe(callFromAutoComplete, node, val, e)) { |
There was a problem hiding this comment.
null value is a good match in auto-completion
| } else if (compareResult === 0) { | ||
| } else if ( | ||
| compareResult === 0 || | ||
| ((node.value === null || node.type === 'null') && node.length === 0) // node with no value can match any schema potentially |
There was a problem hiding this comment.
null yaml value is a good match for sub-schemas, similar to isAutoCompleteEqualMaybe for const and enums
| if ( | ||
| !maxOneMatch && | ||
| !subValidationResult.hasProblems() && | ||
| (!bestMatch.validationResult.hasProblems() || callFromAutoComplete) |
There was a problem hiding this comment.
(!bestMatch.validationResult.hasProblems() || callFromAutoComplete) didn't solve the previous problem properly
problem was when the order of the subschemas in anyOf changed.
this previous fix allows 'issues' only on the previous bestMatch
|
Bump, I came across the same issue, I made a PR that also adds some gracefulMatching behaviour (naming is hard...) #1048 |
|
@p-spacek Please resolve the conflicts |
|
@msivasubramaniaan thanks for review |
4 participants
What does this PR do?
improve compare mechanism that should choose correct schema alternatives
What issues does this PR fix or reference?
fixes this issue #684
replces this PR #759
Is it tested? How?
added tests