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/MDSAL-74 mdsal <p>It would be nice to add null check to generated java DTO for attributes which represents elements with "mandatory true" in yang.</p> <p>Preconditions.checkNotNull could be added in a constructor of java DTO implementation.</p> <p>Operating System: All<br/> Platform: All</p> MDSAL-74

null check for mandatory fields

Improvement Confirmed Unresolved Unassigned Martin Sunal Fri, 6 Mar 2015 16:05:25 +0000 Sat, 16 Mar 2019 16:12:38 +0000 Binding codegen 0 6 <p>Hi,</p> <p>Since the bug is, to check for null, particularly for the presence of mandate statement with true value, in generated java DTO, we can narrow the change to, leaf element only.</p> <p>Note: However as per RFC definition "A mandatory node is one of-<br/> o A leaf, choice, or anyxml node with a "mandatory" statement with<br/> the value "true".<br/> o A list or leaf-list node with a "min-elements" statement with a<br/> value greater than zero.<br/> o A container node without a "presence" statement, which has at<br/> least one mandatory node as a child."<br/> We can raise new bug for the other two.</p> <p>So, for this bug the expected location of change, as per my understanding and analysis, should be in one of the constructors of class LeafSchemaNodeBuilder.java (yang-parser-impl module).</p> <p>Please correct me if I am wrong on this.Thereby the change look something like following :</p> <p>public LeafSchemaNodeBuilder(final String moduleName, final int line, final QName qname, final SchemaPath path,<br/> final LeafSchemaNode base) {<br/> ...<br/> if ((base instanceof LeafSchemaNode) &amp;&amp; constraints.isMandatory()) </p> { this.type = Preconditions.checkNotNull(base.getType(), "Type must not be null, since mandate statement is true"); } <p> else </p> { this.type = base.getType(); } <p> ...<br/> }</p> <p>Please give me a go ahead on above so that I can proceed with checkin of same.</p> <p>Rashmi</p> <p>Right, the check should be done for either leaves, as well well any structural container children which are between the current object and a mandatory leaf.</p> <p>The change should not be made to LeafSchemaNodeBuilder (or any yangtools component), but rather the code generator templates.</p> <p>Furthermore I do not think this is feasible with the current binding specification, because the generated objects are shared between groupings and their instantiations. Each instantiation can specialize the mandatory flag (as well as constraints). This means that the class itself does not know the details of what really is mandatory and what not. Consider the these two cases:</p> <ul class="alternate" type="square"> <li>refine which makes a leaf mandatory<br/> grouping foo {<br/> leaf foo { type string; } <p>}</p></li> </ul> <p>container bar {<br/> uses foo {<br/> refine foo </p> { mandatory true; } <p> }<br/> }</p> <ul class="alternate" type="square"> <li>refine which makes a leaf non-mandatory<br/> grouping foo {<br/> leaf foo { type string; mandatory true; } <p>}</p></li> </ul> <p>container bar {<br/> uses foo {<br/> refine foo </p> { mandatory false; } <p> }<br/> }</p> <p>No assignee -&gt; Confirmed. Also depends on binding spec 2, as not in comment.</p> Blocks MDSAL-237 Duplicate MDSAL-125 YANGTOOLS-415 Development External issue ID 2797 External issue URL Issue Type ODL SR Target Milestone Rank 0|i02w5j: