[MDSAL-503] Wrongly generated java code using derived type Created: 17/Dec/19 Updated: 18/Jan/24 |
|
| Status: | Confirmed |
| Project: | mdsal |
| Component/s: | Binding codegen |
| Affects Version/s: | None |
| Fix Version/s: | 14.0.0, 13.0.1 |
| Type: | Bug | Priority: | High |
| Reporter: | Miroslav Kovac | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | pt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Description |
|
leaf foo that is of derrived type STRING which is string with some pattern restriction. And this derived type is further more restricted with length which is valid will generate java code that is invalid as follows
BarImpl(BarBuilder base) {
super(base.augmentation);
if (base.key() != null) {
this.key = base.key();
} else {
this.key = new BarKey(base.getFoo());
}
this._foo = key.getFoo();
}
private final STRING _ruleKey public String getRuleKey() { return _ruleKey; }
reproducer model: module foo {
namespace "foo";
prefix "foo";
import bar {prefix exa;}
grouping option60-match-rules {
description "Option60 Match Rules";
leaf rule-key {
description "Key of rule";
type exa:STRING {
length "1..32";
}
}
}
augment "/exa:config" {
container cpe-image-mgmt {
container match-rule {
description "Match rules configuration";
list option60 {
key "rule-key";
uses option60-match-rules;
}
}
}
}
}
module bar {
namespace "bar";
prefix exa;
include bar-types;
container config;
}
submodule bar-types {
belongs-to bar {
prefix exa;
}
typedef STRING {
type string{
pattern "(.*)";
}
description "string";
}
}
|
| Comments |
| Comment by Robert Varga [ 28/Feb/20 ] |
|
Can you provide a reproducer model, please? |
| Comment by Miroslav Kovac [ 02/Mar/20 ] |
|
Description upgraded with models |
| Comment by Robert Varga [ 02/Mar/20 ] |
|
Seems to be related to MDSAL-405 and thereabout. |
| Comment by Robert Varga [ 11/Mar/21 ] |
|
Okay, so this is related to typedefs and their specializations, not specific to string. The simplest reproducer is:
module foo {
namespace foo;
prefix foo;
typedef foo {
type binary;
}
container bar {
leaf baz {
type foo {
length 1;
}
}
}
}
Resulting BarBuilder's setBaz() method fails to check Foo's restrictions, as would be done for the case of: container bar {
leaf baz {
type binary {
length 1;
}
}
}
This is most likely related to the fact that an alternative way to deal with this particular problem is to generate a class for 'foo' specialization: interface Bar { public static final class Baz extends Foo { // ... } public Baz getBaz(); similar in mechanics (but not in overall class naming) to what would be generated for: module foo {
namespace foo;
prefix foo;
typedef foo {
type binary;
}
typedef baz {
type foo {
length 1;
}
}
container bar {
leaf baz {
type baz;
}
}
}
We need to carefully balance the two approaches and decide which should take precendence.
|
| Comment by Robert Varga [ 24/Jun/21 ] |
|
We have all the infrastructure for this and I think we want to generate an enforcer in the builder. Punt to 8.0.1, where we can easily retrofit this. |