[YANGTOOLS-568] Remove AugmentationIdentifier and AugmentationNode Created: 08/Jan/16 Updated: 21/Jun/23 Resolved: 18/May/23 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | codecs, data-api, data-impl, data-util |
| Affects Version/s: | None |
| Fix Version/s: | 11.0.0 |
| Type: | Improvement | Priority: | High |
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | pt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Epic Link: | Redesign NormalizedNode | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Our current way of mapping augmentations onto the data tree relies on the declared model rather than effective model. This means that when a model contains multiple augmentations to the same target node, we treat them as separate entities. This leads to problems when leaves move across these augmentations, where the leaf address changes, even when the effective model remains unchanged. Given a base model: container foo {
}
Revision 1 of a second model: augment base:foo {
leaf foo;
}
augment base:foo {
leaf bar;
}
and revision 2 of the second model: augment base:foo {
leaf bar;
leaf foo;
}
The effective model and data tree layout of both revisions of the second model must remain the same. This requires introduction of a replacement for YangInstanceIdentifier.AugmentationIdentifier, which will be a subclass of AbstractPathArgument. It's node type will be constructed from the QNameModule of the model definiting the augmentation and its localname will be 'augmentation'. The use of this special case needs to be checked for conflicts. The parser needs to squash multiple augment instances into a single effective one, which contains all leaves. The DataTree should provide compatibility for lookups of the data, while the leaves need to be stored in the unified form. |
| Comments |
| Comment by Robert Varga [ 12/Jan/16 ] |
|
This turns out to be a problem only with inconsistent handling of SchemaContext. The data tree should get reformatted to match the new schema context. Since at that step the data tree sees both old and new layout, it should be possible to reformat. Unfortunately exploring this avenue brings out a couple of other issues related to model lifecycle, especially when models are (temporarily) removed from the container. At any rate this particular activity will not solve anything, so I am closing it. |
| Comment by Robert Varga [ 01/Sep/16 ] |
|
Re-opening for follow-up once we get rid of bind spec 1. |
| Comment by Robert Varga [ 15/Nov/20 ] |
|
Actually there is way to recover here gracefully. The impedance is that augmentation as per RFC7950 semantics is just a namespace. Our AugmentationIdentifier matches this semantics in the sense that each augmentation is only a partial view of the overall augmentation effect. Each AugmentationIdentifier is not really a Set<QName>, but rather a QNameModule and Set<UnqualifiedQName>. I.e. it is a filter on data schema nodes having a particular namespace and then selects an arbitrary one. This also partially solves the impedance between NodeIdentifier and AugmentationIdentifier re. getNodeType() – the latter has at least the namespace (which is really people are after some of the time at least. |
| Comment by Robert Varga [ 15/Nov/20 ] |
|
As for recovery: if we mis-identify a leaf, we can search the augmentation's siblings to locate the correct schema and attach it to the child. Not the nicest of things, but should work well enough. |
| Comment by Robert Varga [ 18/May/21 ] |
|
Another thing here is that the DataNodeContainer.resolveChild() does not enforce the normalized structure when dealing with augmentations. For example this model: module foo {
namespace foo;
prefix foo;
container foo;
augment /foo {
leaf bar {
type string;
}
}
}
will happily accept foo/bar structure as well as foo/augmentation/bar structure. We need would be rejecting one of the addressing modes, otherwise we are at risk of having weird interop problems. |
| Comment by Robert Varga [ 01/Nov/22 ] |
|
Rather than attempting to fix all the issues here, let us just get rid of AugmentationNode and AugmentationIdentifier. This will put a burden on mdsal-binding-dom-codec (to transcode) and mdsal-binding-dom-adapter (to adapt datastore operations), but will end up with a clean yang-data-api model without ambiguities. |