[MDSAL-74] null check for mandatory fields Created: 06/Mar/15 Updated: 16/Mar/19 |
|
| Status: | Confirmed |
| Project: | mdsal |
| Component/s: | Binding codegen |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | ||
| Reporter: | Martin Sunal | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||||||||||||||
| Description |
|
It would be nice to add null check to generated java DTO for attributes which represents elements with "mandatory true" in yang. Preconditions.checkNotNull could be added in a constructor of java DTO implementation. |
| Comments |
| Comment by Rashmi Tomer [ 01/Dec/15 ] |
|
Hi, 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. Note: However as per RFC definition "A mandatory node is one of- 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). Please correct me if I am wrong on this.Thereby the change look something like following : public LeafSchemaNodeBuilder(final String moduleName, final int line, final QName qname, final SchemaPath path, else { this.type = base.getType(); } ... Please give me a go ahead on above so that I can proceed with checkin of same. Rashmi |
| Comment by Robert Varga [ 01/Dec/15 ] |
|
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. The change should not be made to LeafSchemaNodeBuilder (or any yangtools component), but rather the code generator templates. 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:
container bar { }
container bar { } |
| Comment by Robert Varga [ 21/Jun/16 ] |
|
No assignee -> Confirmed. Also depends on binding spec 2, as not in comment. |