[YANGTOOLS-556] yang-data-api: use yang.common.Decimal64 for decimal64 leaves Created: 23/Nov/15 Updated: 10/Apr/22 Resolved: 13/Mar/22 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 8.0.0 |
| Type: | Improvement | Priority: | Highest |
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||||||
| Epic Link: | Redesign NormalizedNode | ||||||||||||
| Description |
|
Using BigDecimal does not really work for handling of decimal64 type semantics. It does not enforce the set of allowed ranges, nor values. Create a dedicated subclass of java.lang.Number, which will implement exact http://tools.ietf.org/html/rfc6020#section-9.3 decimal64 as a long field to hold the value and the scaling value (1-18). Comparable<Decimal64> needs to be implemented (using adjusting scales as needed). The toString() should emit the canonical representation. valueOf(String) should accept any legal representation. A migration strategy for NormalizedNode users needs to be devised, as a straight switchover would break current users, who assume BigDecimal. This should probably involve a 'TypeValueSupport' interface, which would be used to access the value inside the leaf. Implementations would perform dynamic translation as needed. Evaluate the resulting interface for use in the solution for YANGTOOLS-418. |
| Comments |
| Comment by Tony Tkacik [ 01/Mar/16 ] |
|
Consider putting Decimal64 to yang-common or util, so it is available also to Java Binding, without direct need of dependening on yang-data-api |
| Comment by Robert Varga [ 01/Mar/16 ] |
|
Preliminary patch https://git.opendaylight.org/gerrit/#/c/31897/, needs to be finished. |