-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Chopps/oper choice case #15131
Chopps/oper choice case #15131
Conversation
Signed-off-by: Christian Hopps <[email protected]>
Signed-off-by: Christian Hopps <[email protected]>
79df49c
to
7b7725f
Compare
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.
I have one question.
"c1value": 21, | ||
"c2cont": { | ||
"c2value": 2868969987 | ||
} |
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.
It looks wrong that we simultaneously have values from two different cases of a choise in our result. I think it's a violation of the RFC https://datatracker.ietf.org/doc/html/rfc8342#section-5.3. It says about operational datastore:
Only semantic constraints MAY be violated. These are the YANG
"when", "must", "mandatory", "unique", "min-elements", and
"max-elements" statements; and the uniqueness of key values.
Syntactic constraints MUST NOT be violated, including hierarchical
organization, identifiers, and type-based constraints. If a node in
<operational> does not meet the syntactic constraints, then it
MUST NOT be returned, and some other mechanism should be used to flag
the error.
This seems like a hierarchical organization to me that should not be violated. Should we use lyd_validate_all
with LYD_VALIDATE_OPERATIONAL
option somewhere at the end to make sure we don't produce an incorrect operational tree?
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 is on purpose. We should trust the backend to get this right, or it's a bug in the backend. I don't see a reason to extra-police this at the cost of CPU time and complexity.
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.
Sounds fine. We can always add a validation later if we decide that it's necessary. Merging.
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.
I did think about the fact that the test case violated the standard, but then figured it was also OK since the testing framework here is too simple and it highlighted the fact that the backend could do this. I have more tests i did locally that we can work back in once we have some implemented models with real choice/case stements. :)
Implement missing oper-state choice/case support.