[YANGTOOLS-702] Improve mapping of YANG extensions Created: 26/Oct/16 Updated: 10/Apr/22 Resolved: 05/Jun/17 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Highest |
| Reporter: | Robert Varga | Assignee: | Peter Kajsa |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||||||
| Epic Link: | Parser Performance | ||||||||||||
| External issue ID: | 7037 | ||||||||||||
| Description |
|
Our current handling of statements within a YANG extension performs encapsulation into UnknownNodes – this is done in the middle of SourceSpecificContext.createDeclaredChild(). As the associated FIXME indicates, the way this is done is inefficient, as we end up creating a new ModelDefinedStatementDefinition and a corresponding UnknownStatementImpl.Definition for each such instance. In order to fix this we have to change the way we look up StatementDefinitionContext when creating a ContextBuilder. Instead of going directly to BuildGlobalContext, we should consult current StatementContextBase.definition(), which should return a StatementDefinitionContext for the requested child:
public StatementDefinitionContext getChildStatementDefinition(QName, SchemaSourceReference) { final StatementSupport<?, ?, ?> childSupport = support.getChildSupport(qname); SourceException.throwIfNull(childSupport, sourceReference, "Unsupported statement %s", qname); ... (consult & populate cache) ... }
There really need to be two implementations:
This may mean we need to update what StatementDefinitionContext.substatementBuilder() does... |
| Comments |
| Comment by Peter Kajsa [ 20/Apr/17 ] |