[YANGTOOLS-1127] Fix SchemaContextUtil.findDataSchemaNodeForRelativeXPath() Created: 30/Jul/20 Updated: 17/Mar/21 Resolved: 16/Feb/21 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.0.0 |
| Type: | Bug | Priority: | High |
| Reporter: | Ilya Igushev | Assignee: | Miroslav Kovac |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Epic Link: | Get rid of SchemaNode.getPath() | ||||||||||||||||
| Description |
|
On resolving relative paths for key_leaf1 and leaf2 leafrefs(with findDataSchemaNodeForRelativeXPath) SchemaContextUtil.resolveRelativePath() returns incorrect paths. module
module a {
yang-version 1;
namespace "a";
prefix "a";
grouping foo_grp {
leaf key_leaf1 {
type leafref {
path "../../../../../../a:foo_cont/a:name";
}
}
}
container bar_cont {
leaf leaf2 {
type leafref {
path "../../../../../../a:foo_cont/a:name";
}
}
}
}
Incorrect paths: for leaf2: [(a)bar_cont, (a)leaf2, (a)foo_cont, (a)name] On call findDataSchemaNodeForRelativeXPath with leaf2 fails with
java.lang.IllegalArgumentException: Path [(a)bar_cont, (a)leaf2, (a)foo_cont, (a)name] extends beyond terminal child
On call findDataSchemaNodeForRelativeXPath with key_leaf1 returns null.
Let's check whether the path goes behind grouping root node or root node of a different type. With this improvement, we will not lookup knowingly incorrect paths.
|
| Comments |
| Comment by Ilya Igushev [ 17/Nov/20 ] |
|
Gerrit change is a correctly working solution, but it is dirty. createWalkablePath, resolveRelativePath, findTargetNode should be refactored in order to get rid of such conditionals: Possibly divide every method into two versions one for when the root node of a relativePath is a grouping and another one when not. |
| Comment by Robert Varga [ 28/Jan/21 ] |
|
This entire method needs to go. Its input context is woefully inadequate to actually perform the task. Also the implementation parses strings – for an input which already have as structured input! So we actually need to add the following method to SchemaInferenceStack:
void enterPath(PathExpression path); This will need to operate on both absolute and relative path, but that distinction is very simple (absolute == rewind to root and perform relative). The implementation can follow PathExpression.getSteps() rather than getOriginalString() it currently takes.
|