[YANGTOOLS-620] yang-model-api: define a structured type for union values Created: 09/Jun/16 Updated: 10/Apr/22 |
|
| Status: | Confirmed |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | ||
| Reporter: | Robert Varga | 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 |
|
Union values are a nasty beast, as they are polymorphic and do not really have a native type. RFC6020(bis) maps their type to the first conforming member, which means each time we want to instantiate a union DTO (in Java Bindings, but this is not specific to them), we have to check each possibility until we find a match. This is especially troublesome unions of exotic types like binary, where the cost of getting the common representation cost quite a few CPU cycles. Introduce a dedicated value class for use with union types, which aside from the value in native type will hold the SchemaPath of the type being stored. It needs to be exposed as an Optional<SchemaPath> for compatibility with schema-less producers. This would probably be also beneficial for String types, where we get it trouble with Binding subclasses. |
| Comments |
| Comment by Robert Varga [ 22/Feb/18 ] |
|
YANGTOOLS-675 will need this structured information to reinterpret unions during datastore operations. |
| Comment by Robert Varga [ 25/Mar/19 ] |
|
Punting this to 4.0.0, because the proposed design will not work. The problem is that members within a union cannot be reliably addressed through SchemaPath, for example in this case:
union foo {
type string {
pattern "a";
}
type string {
pattern "b";
}
type union {
type uint8t;
}
}
Furthermore SchemaPath is a yang-model-api, whereas we need to identify the types in terms of yang-common. We could go with simple integers, but we probably also want some amount of support from the parser, i.e. similar to CanonicalValue. |