[MDSAL-426] Specialize relative leafref types during instantiation Created: 18/Mar/19  Updated: 12/Mar/22  Resolved: 19/Dec/20

Status: Resolved
Project: mdsal
Component/s: Binding codegen
Affects Version/s: None
Fix Version/s: 7.0.3

Type: Improvement Priority: Medium
Reporter: Robert Varga Assignee: Ilya Igushev
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by MDSAL-182 Java binding v1: leafref up two conta... Resolved
Relates
relates to MDSAL-528 Failed to find leafref target using s... Resolved
relates to MDSAL-533 Generated code with incompatible types Resolved
relates to MDSAL-651 yang-maven-plugin:6.0.2 error while g... Resolved
relates to MDSAL-518 leafref path outside of augmented sco... Resolved
relates to MDSAL-732 Binding generator generates uncompila... Resolved

 Description   

MDSAL-182 uncovers a case where a grouping definition cannot fully resolve the type of a leaf. The solution is to fall back to java.lang.Object.

This solution needs to be further improved, as in some cases we can determine what the type is, for example in:

    grouping foo {
        leaf foo {
            // java.lang.Object
            type leafref {
                path "../../bar";
            }
        }
    }

    container one {
        leaf bar {
            type string;
        }
        // leaf foo is java.lang.String
        uses foo;
    }

    container two {
        leaf bar {
            type uint16;
        }
        // leaf foo is java.lang.Integer
        uses foo;
    }

Both One and Two can specialize their return type to either String or Integer and have their Builders require the proper type. This obviously needs to work with groupings, too:

    grouping foo {
        leaf foo {
            type leafref {
                path "../../bar";
            }
        }
    }

    grouping one {
        leaf bar {
            type string;
        }
        uses foo;
    }

    container cont {
        uses one;
    }

This also means grouping copy builders need to take specializations into account and perform checkArgument() to determine if the source grouping actually has a compatible specialization.



 Comments   
Comment by Ilya Igushev [ 17/Nov/20 ]

Generating bindings part is done(mdsal-binding-java-api-generator, mdsal-binding-generator -api,  mdsal-binding-generator -impl,  mdsal-binding-generator -util) 

Comment by Ilya Igushev [ 18/Nov/20 ]

There is a high probability that codec will not like Boolean getFoo() in some shape or form specifically BindingReflections. isFoo should be removed and substituted with getFoo, in such way codec adjustment will be simplified.

Generated at Wed Feb 07 20:09:46 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.