[YANGTOOLS-738] SchemaContext: unique SchemaNodeidentifiers Created: 20/Jan/17 Updated: 10/Apr/22 Resolved: 11/Feb/20 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | ||
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||||||||||
| Description |
|
Since a SchemaContext is an immutable entity containing children which get referenced a lot, it would nice to have a really quick identifier unique within a SchemaContext instance. We have implemented something similar for declared statements in yang-parser-impl by each substatement track the (int) offset in which it appears in its parent. This allows quick lookups in the form of /2/7/0/1 to express the SchemaPath within a SchemaContext – extremely useful when there is some schema-specific state being tracked. |
| Comments |
| Comment by Robert Varga [ 12/Jun/18 ] |
|
This is a bit more complex, and should not really be done in the context of SchemaNodes, but rather in EffectiveStatements. The identifier needs to understand how exactly the node is being identifier: is it via data tree or schema tree? |
| Comment by Robert Varga [ 01/Jan/19 ] |
|
This boils down to a StatementIdentifier and it should work solely on the statement tree, irrespective of data/schema trees. |
| Comment by Robert Varga [ 08/Jan/20 ] |
|
I am not sure how useful this is. In most contexts where we would lookup a SchemaNode/EffectiveStatement we should really have a stack of SchemaNode/EffectiveStatements with the topmost element being the one that is being resolved. This is used for example in leafref resolution, where we have relative paths involving parent steps – with such a stack we can accurately follow what is going on. So this really is only useful in serialization scenarios – in which case that would be a function of the 'statement stack' class. |
| Comment by Robert Varga [ 13/Jan/20 ] |
|
Maintaining this identifier is actually a reference to parent, as for example statements created by 'uses' can have the entire definition shared in a particular namespace (most probably), but they would end up needing to differ in this int – which can be addressed by flyweight objects, but it feels like an unnecessary complication. |
| Comment by Robert Varga [ 11/Feb/20 ] |
|
This issue runs against https://jira.opendaylight.org/browse/YANGTOOLS-1066 deliverables and would prevent us from sharing SchemaNode instances, closing it down. |