https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/YANGTOOLS-843 yangtools <p>The schema path represents unique path to every node inside module.<br/> We should resolve the issue of two nodes with same qname and schema path, such as in a module:<br/> container test {}<br/> grouping test {}</p> YANGTOOLS-843

The schema path should be unique to every schema node inside the module.

Bug Medium Resolved Won't Do Jie Han Jie Han Tue, 9 Jan 2018 01:52:03 +0000 Wed, 8 Jan 2020 23:04:02 +0000 Wed, 8 Jan 2020 23:03:38 +0000 parser 0 2 <p><a href="https://git.opendaylight.org/gerrit/66848" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/66848</a><br/> <a href="https://git.opendaylight.org/gerrit/66850" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/66850</a></p> <p>I think this needs a way better description and justification. What is the precise problem we are trying to solve here?</p> <p>Note that usual run-time users do not concern themselves with groupings (which really are a leak from declared model and should end up being eliminated from the effective model).</p> <p>The problem was actually met in class ModuleContext at first, for there're many<br/> maps which take schema path as the key, such as below:</p> <blockquote><p>private final Map&lt;SchemaPath,GeneratedTOBuilder&gt; genTOs = new HashMap&lt;&gt;();<br/> private final Map&lt;SchemaPath, Type&gt; typedefs = new HashMap&lt;&gt;();<br/> private final Map&lt;SchemaPath, GeneratedTypeBuilder&gt; childNodes = new HashMap&lt;&gt;();<br/> private final BiMap&lt;String, GeneratedTypeBuilder&gt; dataTypes = HashBiMap.create();<br/> private final Map&lt;SchemaPath, GeneratedTypeBuilder&gt; groupings = new HashMap&lt;&gt;();<br/> private final Map&lt;SchemaPath, GeneratedTypeBuilder&gt; cases = new HashMap&lt;&gt;();</p></blockquote> <p>See the blocked issue "<a href="https://jira.opendaylight.org/browse/MDSAL-271" title="About Namespace" class="issue-link" data-issue-key="MDSAL-271"><del>MDSAL-271</del></a> About Namespace": <br/> <a href="https://jira.opendaylight.org/browse/MDSAL-271" class="external-link" rel="nofollow">https://jira.opendaylight.org/browse/MDSAL-271</a><br/> in that case, all these maps above may conflicts for the same schema path but diffrent schema nodes. <br/> Another case here is the implementation from uses node which is a litte complex, for example:</p> <p>container test {<br/> container test {<br/> }<br/> }<br/> grouping test {<br/> container test {<br/> }<br/> }<br/> grouping test2 </p> {uses test; } <p>The generated class Test for container test in grouing test2 (added by uses) would implement the class Test generated by container test in grouping test, but when we try to use an orginal schema path of the uses node to get the original node, it would find the wrong one - the inner container test in container test at the top level.<br/> Such problems would always happen in many cases in the generator.</p> <p>Indeed that usual users don't care about the groupings but data schema nodes.<br/> So we had better to provide two kinds of schema paths：<br/> 1) DataSchemaPath - for usual runtime users, which would try to find node from only data schema node, not groupings.<br/> 2) SchemaPath - for generator most, which would find node from both data schema node and groupings.<br/> And as a result two APIs comes after them:<br/> 1) findDataSchemaNode(..., DataSchemaPath dataPath) - for usual users<br/> 2) findSchemaNode(..., SchemaPath schemaPath) - for generator</p> <p>Another way to reslove this is to eliminate groupings from effective models, by then the generator would generate classes from uses nodes alone without implementations , and also it would clean everything about groupings.</p> <p>As described in RFC7950 section 5.4:</p> <blockquote><p>For example, if a module defines a grouping in which a type is<br/> referenced, when the grouping is used in a second module, the type is<br/> resolved in the context of the original module, not the second<br/> module. There is no ambiguity if both modules define the type.</p></blockquote> <p>it seems necessary to keep groupings. <br/> And also for yang snippet,<br/> grouping grp {<br/> leaf my-leaf {<br/> type union {<br/> type int32;<br/> type enumeration </p> { enum "unbounded"; } <p> }<br/> }<br/> The union SHOULD only be generated in grouping grp.</p> <p>Well, from the overall direction at some point we should be ditching SchemaNodes in their current shape and form and we cannot really change the semantic meaning of SchemaPath – no matter how flawed it currently is, as it is used all over the place in contexts which actually work okay, as they simply do not deal with groupings and their instantiations.</p> <p> </p> <p>Use of SchemaPath in those maps is flawed and was supposed to be fixed (note how these things are essentially copy&amp;pasted from binding v1) – I would suggest binding v2 defining a SchemaNodeIdentifier for non-conflicting identification and construct the tracking maps using that. If/when that approach is qualified as sound we can promote that concept to be the replacement for SchemaPath.</p> <p>Defining a SchemaNodeIdentifier in binding v2 would still not work, for the original schema path from uses node which was constructed by yangtools<br/> was still SchemaPath by using which we still could not find the correct original schema node and then could not add class of implementation.</p> <p>Right. Another question: would it be feasible to use IdentityHashMaps keyed by actual SchemaNodes? A cursory glance shows that that's how they are effective accessed...</p> <p>In that way, APIs in yang-model-api such as UsesNode which provides getGroupingPath or AugmentationSchemaNode provides getTargetPath and so on, all these sort of nodes should also provide like 'getGroupingNode' or getTargetNode', in one word, 'getXXXNode' should appear any where getXXXPath appears.</p> <p>Well, SchemaNodes are on their way out, so I do not believe we want to retrofit SchemaPath (or anything else) to fit their twisted model. EffectiveStatement is the replacement, where any statement can be addressed using a combination of:</p> <ul> <li>List&lt;QName&gt; along schema tree</li> <li>List&lt;QName&gt; along data tree</li> <li>Statement type + offset</li> </ul> <p>I do not believe we need addressing beyond the first two items of that list. Hence I am inclined to turn this issue into a 'Define StatementPath to address effective statements'. Binding concerns, such as finding in what grouping a particular definition comes from should really be computed/cached in MD-SAL, not SchemaContext (and its equivalents).</p> <p>This issue centers around SchemaPath, but we have an alternative in <a href="https://jira.opendaylight.org/browse/YANGTOOLS-738" title="SchemaContext: unique SchemaNodeidentifiers" class="issue-link" data-issue-key="YANGTOOLS-738"><del>YANGTOOLS-738</del></a>. The difference is that while this issue request each node to retain a global identifier (path), <a href="https://jira.opendaylight.org/browse/YANGTOOLS-738" title="SchemaContext: unique SchemaNodeidentifiers" class="issue-link" data-issue-key="YANGTOOLS-738"><del>YANGTOOLS-738</del></a> retains an identifier within the context of a parent.</p> <p>This effectively means that instead of having a SchemaNode-&gt;Path and SchemaContext-&gt;Path-&gt;SchemaNode lookup we would maintain the identifier externally, if that is even useful.</p> Blocks MDSAL-271 Relates YANGTOOLS-738 Development Rank 0|i039cn: