[YANGTOOLS-1271] Expose SchemaInferenceStack.effectiveConfig() Created: 13/Apr/21  Updated: 18/Jan/24

Status: Confirmed
Project: yangtools
Component/s: model-api, model-util
Affects Version/s: None
Fix Version/s: 14.0.0, 11.0.6, 13.0.2

Type: Improvement Priority: High
Reporter: Robert Varga Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: pt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to YANGTOOLS-1272 Expose SchemaInferenceStack.effective... Resolved
Epic Link: Accurate EffectiveStatements

 Description   

Current parser does not accurately process config statements, relying on DocumentedNode's and explicit lookups in parent. This means that users looking through EffectiveStatement hierarchy do not always see the config substatement when they should.

For example, given the following model:

 

module foo {
  prefix foo;
  namespace foo;

  grouping grp {
    container foo;
    container bar {
      config false;
    }
  }

  container baz {
    uses grp;
  }

  container oper {
    uses grp;
    config false;

    container cont;
  }

  rpc xyzzy {
    input {
      uses grp;
    }
  }
}

Should observe the following:

  • baz should have an implicit 'config true' substatement (as it is the default)
  • baz/foo should have an implicit 'config true' substatement (as it is the default/implied by parent)
  • oper/foo should have an implicit 'config false' substatement (as it is implied by parent)
  • oper/cont should have an implicit 'config false' substatement (as it is implied by parent)
  • xyzzy/input/bar should not have a config substatement (as it is instantiated in a context which ignores config)

 Note this has implications on memory efficiency and general lifecycle of uses/augment mechanics, hence we need to carefully evaluate the solution.

 Comments   
Comment by Robert Varga [ 01/Dec/21 ]

At least the conjuring part needs purely-effective statements.

The suppression part can probably work in similar way as deviate works.

Comment by Robert Varga [ 12/Dec/21 ]

The current requirement is really driven by DataSchemaNode.effectiveConfig(), i.e. the statement itself needs to know its effective configuration. This is important in SchemaNode world, as all its users usually work on a single SchemaNode, with the odd exception here and there where also the parent DataNodeContainer is considered.

In EffectiveStatement world, though, having this knowledge directly in the statement is not as critical. Users here typically work with EffectiveStatementInference, which conceptually captures the path from  root. We also have SchemaInferenceStack as the baseline utility for all sorts of inferences on the statement tree.

Hence if we take SchemaNodes out of the picture, we could expose this information from SchemaInferenceStack, i.e. host DataSchemaNode.effectiveConfig() there and calculate the result based on stack. With such a design we can almost ditch the flags field from effective statements, allowing for a much more aggresive statement reuse in the parser.

Unfortunately this is somewhat counter-intuitive from object model perspective, as config/status end up not being strictly effective

Comment by Robert Varga [ 25/Jan/23 ]

The last sentence is okay. What we need to ensure is that we document EffectiveConfigStatement mechanics explicitly – both in its description and call it out in the general model.api.stmt contract description.

Generated at Wed Feb 07 20:55:40 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.