Basically I have two RPC operations :

rpc create-device-config {

                input {
                                uses device-config-info;
                }

                output {
                                leaf status {
                                                type string;
                                                description "returns the status 
of operation";
                                }
                                leaf error-message {
                                                type string;
                                                description "failure message 
will be indicated otherwise empty";
                                }
                                
                }
}

rpc update-device-config {

                input {
                                uses device-config-info;
                }

                output {
                                leaf status {
                                                type string;
                                                description "returns the status 
of operation";
                                }
                                leaf error-message {
                                                type string;
                                                description "failure message 
will be indicated otherwise empty";
                                }
                                
                }
}


    typedef device-type-t {
        type enumeration {
            enum switch;
            enum router;
        }
       default switch;
    }


grouping device-config-info {
  list device-config {
                key uid;

                leaf hostname {
                                type string;
                                mandatory true;
                                description "Host name of the device";
                }
                                
                leaf device-type {
                                type device-type-t;
                                description "Type of the device being 
configured";
                }
}

Assume this scenario. NBI user invokes the create-device-config and passes UID, 
hostname and the device-type  attribute value as 'router''. Then the code which 
processes the create-device-config stores these values in the datastore. Now 
the NBI user just wants to change the hostname. So he invokes the 
update-device-config RPC and passes the UID, hostname attribute but does not 
pass the device-type  attribute . So the UpdateDeviceConfig will have the 
device-type attribute value as 'switch' . But I have a validation in the update 
processing code which prevents the deviceType not to be changed. But in our 
case the NBI user just wants to change the hostname attribute and is not 
bothered to change the device type. So how can I determine in the update case 
that the device-type  attribute is not injected  by the yang so that I can 
validate. OR is there any other way in which I can proceed ?

Regards
-Satish

-----Original Message-----
From: Robert Varga [mailto:n...@hq.sk] 
Sent: Monday, March 13, 2017 5:11 PM
To: Satish Dutt <sd...@advaoptical.com>; yang-push-...@lists.opendaylight.org; 
yangtools-us...@lists.opendaylight.org; yangtools-...@lists.opendaylight.org; 
controller-us...@lists.opendaylight.org; controller-dev@lists.opendaylight.org
Subject: Re: [yangtools-dev] Query regarding the default value of an attribute 
in yang model

On 03/13/2017 12:25 PM, Satish Dutt wrote:
> *_Is there any way in the Java code which processes the RPC request. 
> to know if the 'device-type' value was passed by the NBI user or the 
> default value auto-injected by the yang ?_*

Depends on what 'Java code' means.

Binding-Independent APIs do not inject default values, as the applications are 
expected to have a SchemaContext available and hence can look up the value. 
This is appropriate for data funneling type of applications expected at this 
layer.

Binding-Aware APIs inject the default value as the applications do not have a 
means to look them up and should not care about the source of the date -- the 
semantics is the same. This is appropriate for model-specific applications, 
which bind to model semantics.

Why would you need to differentiate between the two?

Regards,
Robert

_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Reply via email to