Cdb_get_modification return value does not return correct value

CDB and CDB API
1

My data model have a list node. which contain a key, a configuration leaf and and operational leaf.

Now i have subscribed

cdb_subscribe2(subsock, CDB_SUB_RUNNING_TWOPHASE, DAL_DB_SUB_WANT_ABORT_ON_ABORT,  &spoint[1], ns,
                       "/container/listNode/");

cdb_subscribe2(subsock, CDB_SUB_OPERATIONAL, 0, &spoint[2], ns,
                        "/container/listNode/opertionalData");

Now when I change configuration leaf i get below data using cdb_get_modification

(gdb) p taggedValue[0].v.type
$11 = DAL_C_XMLBEGIN // Start List entry
(gdb) p taggedValue[1].v.type
$12 = DAL_C_UINT32   // Key value
(gdb) p taggedValue[2].v.type
$13 = DAL_C_UINT16  // Changed configuration data
(gdb) p taggedValue[3].v.type
$14 = DAL_C_XMLEND // End list entry

But when I change operational leaf i get below data using cdb_get_modification which is not correct. I dont get keyvalue.

(gdb) p taggedValue[0].v.type
## $11 = DAL_C_XMLBEGIN // Start List entry
## (gdb) p taggedValue[1].v.type
## $12 = DAL_C_XMLBEGIN   // Start List entry
(gdb) p taggedValue[2].v.type
$13 = DAL_C_UINT16  // Changed operational data
(gdb) p taggedValue[3].v.type
$14 = DAL_C_XMLEND // End list entry

What is the problem ? is there any problem in my implementation ?

2

Your subscriber path seems to be /container/listNode/ for config and /container/listNode/opertionalData for oper data. Do you use that path when you call cdb_get_modifications()?
That would explain why you don’t get the modifications of the listNode for oper data.

An example on how to print the tagged value array ( see print_modifications() and confd_load_schemas() ):

3

Hi

I am giving path like /container/ in cdb_get_modifications. If i give /container/listNode i dont get any response.

4

Perhaps you can share some YANG to save us from having to guess?

5

Please find testModule using pyang tool

module: testModule
    +--rw mgmt-element
       +--rw function
          +--rw test
             +--rw test-entries* [test-num]
                +--rw test-num         uint32
                +--rw cell-identity?   uint32
                +--ro status?          uint8

Actual yang

module testModule {
    namespace "http://www.testmodule.com/global/test";
    prefix test-module;
    import ietf-inet-types {
        prefix inet;
    }
    import tailf-common {
        prefix tailf;
    }
    container mgmt-element {
        description "Root";
        container function {
            description "Function";
            container test {
                description "test";
                list test-entries {
                    key test-num;
                    description "Entries of test";
                    max-elements 10;
                    leaf test-num {
                        type uint32;
                        description "This parameter indicates test number.";
                    }
                    leaf cell-identity {
                        type uint32 {
                            range "0..4294967295";
                        }
                        description "This parameter is the cell identity.";
                    }
                    leaf status {
                        config false;
                        tailf:cdb-oper;
                        type uint8 {
                            range "0..1";
                        }
                        default 0;
                        description "This parameter defines status of test";
                    }
            }
    }
}
6

Hi,

ConfD’s cdb_get_modifications() will not be smart enough to get the list key from the CDB running datastore too if you place the CDB operational datastore status data leaf on the same level as the key.

However, if you place your status data in a container inside the list, cdb_get_modifications() will get the list key too. cdb_diff_iterate() will get the path including key(s) + the modified value for you.

If you do want to use cdb_get_modifications() with an operational data subscriber for your status data and get the list key, in your example the tree and YANG could be something like this:

module: testModule
    +--rw mgmt-element
       +--rw function
          +--rw test
             +--rw test-entries* [test-num]
                +--rw test-num         uint32
                +--rw cell-identity?   uint32
                +--rw status-data
                   +--ro status?          uint8

container mgmt-element {
        description "Root";
        container function {
            description "Function";
            container test {
                description "test";
                list test-entries {
                    key test-num;
                    description "Entries of test";
                    max-elements 10;
                    leaf test-num {
                        type uint32;
                        description "This parameter indicates test number.";
                    }
                    leaf cell-identity {
                        type uint32 {
                            range "0..4294967295";
                        }
                        description "This parameter is the cell identity.";
                    }
                    container status-data {
                        leaf status {
                            config false;
                            tailf:cdb-oper;
                            type uint8 {
                                range "0..1";
                            }
                            default 0;
                            description "This parameter defines status of test";
                        }
                    }
            }
    }
}