ConfD User Community

How to handle choice and case in get_object/get_next_object calls?

Dear Team,

With reference to “How to implement get_object for a container inside of a list”.

In get_object call flow, how do we need to implement choice-case type and How the hierarchy must be handled? If am trying to set the case using CONFD_SET_TAG_XMLBEGIN & CONFD_SET_TAG_XMLEND am getting the following error in confd_devel.log: Can you please guide me in this.

1-Aug-2020::17:38:32.778 localhost confd[18967]: devel-c bad get_object() return value: /if:interfaces-state/interface{flexe-group/565337}/flexe-group/group{565337}/flexe-channel/channel{18765}/oam/oam-dm-status: one-dm is not a child element

Yang snippet:

            choice choice-dm-type {
                    case one-dm {
                    leaf oam-one-dm{
                            type uint32{
                              range "0..4294967295";
                    case two-dm {
                    leaf oam-two-dm{
                            type uint32{
                              range "0..4294967295";

pyang tree structure:

  augment /if:interfaces-state/if:interface:
    +--ro flexe-group
       +--ro group* [group-id]
          +--ro group-id         uint32
          +--ro port-group
          |  +--ro port-group* [port-group-id]
          |     +--ro port-group-id    uint32
          +--ro flexe-channel
             +--ro channel* [client-id]
                +--ro client-id      uint32
                +--ro oam
                |  +--ro oam-dm-status
                |  |  +--ro dm-type?   delay-measurement-type
                |  |  +--ro (choice-dm-type)?
                |  |  |  +--:(one-dm)
						 |  +--ro oam-one-dm?   uint32
                |  |  |  +--:(two-dm)
						 |  +--ro oam-two-dm?   uint32

i am writing now without cross-checking the docs/manual, so hopefully i’m not confusing this with something else…

oam/oam-dm-status: one-dm is not a child element

All the elements related to choice statement - flagged with () in your Pyang printout, try to leave them out.

If i recall correctly, they are used rarely in one or two callback functions like get_case(), but are generally not part of the tag arrays/keypath strings…

So, no one-dm, no choice-dm-type in your responses/keypaths of requests, etc.

ConfD/lib will imply which case is in effect either by previous get-case callback invocations, or by name of the following data element (leaf/container) in tag array/keypath - due to the fact that you may not have same leaf name in two sibling cases…

so, paths/tag arrays like:


should be fine.

“invalid” paths / corresponding tag arrays:


Thanks for the response @josephm

Explanation clarified few behaviors [Statement flagged with (…) & get_case() calls are not part of tag array].

I can see get_case() after get_object() call for the above mentioned hierarchy, if i see no error - means if not filling tag array for choice statement (of-course, its not recommended as you mentioned).

TRACE CALL data get_object(thandle=17,/interfaces-state/interface{flexe-group/565337}/flexe-group/group{565337}/flexe-channel/channel{20766})2020-08-01 17:17:47:876 --> CONFD_OK
TRACE CALL data get_case(thandle=17, /interfaces-state/interface{flexe-group/565337}/flexe-group/group{565337}/flexe-channel/channel{20766}/oam/oam-dm-status, choice-dm-type)2020-08-01 17:17:47:877 (NOEXISTS) 2020-08-01 17:17:47:881 --> CONFD_ACCUMULATE

While looking at the trace log, seems choice-case statement is decoupled with get_object call. Do we need to fill the choice-case statement data separately during get_case call after get_object? if yes, how do we need to handle for case child elements (container/leafs, if any) - providing sample code snippet will be helpful for my understanding. if am wrong, please correct me.

I would like to align my understanding with your recent post edit.

so, paths/tag arrays like:


should be fine.

Understood that its possible to provide data for choice-case statement in get_object()/get_next_object() calls itself.

In the presence of get_object/get_next_object, get_case registrations must be removed - to void get_case invoke after get_object?

i am not sure myself :slight_smile: i haven’t worked with more complex tagged arrays for quite some time (am not ConfD developer, just sort of more extensive (in some areas) user).
my unverified assumption is that:

  • it should be possible to send specific case items as part of get_object() response data

  • you will probably still need to have get_case() implementation in case confd internally needs / invokes it for some processing

(second point possibly contradicts with my previous statement about confd implying which case is set, but maybe it’s only for some/specific cases)

Unless someone else can confirm/add more info, please test try it, as i assume you have the the above work-in-progress and can verify it more quickly…

assuming my first point above is true, tagged array rules about nested lists/containers/etc. still apply, so if the nested items of choice you have are also “nests” - containers/lists, you can not add all the sub-nested children, only the nest itself - resp. its stub as described/explained in other forum topics/man pages) and there will be subsequent nested calls…

Thanks @josephm

As you said, get_case is required & can send specific case items as part of get_object/get_next_object response data. Confd will initiate separate get_case call to understand the case selection & read the data from get_object/get_next_object response based on it.

1 Like

See also for a reference implementation
The “choice” statement is covered here: