Facing issues in implementing get_next call

CDB and CDB API
1

Hi,

I am implementing get_next api callback for folloiwing yang model.

Yang :-

container policy {
    config false;
    list ks_policy {
        key addr;
        leaf addr {
            type inet:ip-address;
        }
        leaf port {
            type uint8;
        }
    }
}

As mentioned in the Yang the ks_policy is a list with addr as the key.

In the get_next function i am getting next= -1 for first time then i am adding

CONFD_SET_IPV4(&v, in);
confd_data_reply_next_key(tctx, &v, 1, (long)element->next);

In my implementation element->next is NULL so the next time when the get_next is called the variable next should have the value 0 but it is getting called with next as -1 again.

but third time get_next is not getting called. Its getting called for 2 times with next = -1 both the times.

Is there anything i am missing?

Thanks,
Vipin Bansal

2

Hello,

ConfD internally can use get_next() callback not only to get first element, but for other purposes too, e.g. to verify that “some” records exist in the list…

This is the reason why you see get_next(-1) twice, not only once.

Due to how data provider API is defined - and independence of data provider callbacks, this should not cause any problems to your implementation…

Consider any get_next(-1) call as a standalone request - it should not be important what happened before, of what happens after…

Why the callback is not invoked for 3rd time I cannot say without more information - did your callback respond for the “2nd” invocation same way like for the first? Did any of sub-seqent callbacks run with error? (e.g. some get_elem())…

3

Hi,

I have added the printf in both the APi’s(get_next and get_elem).
What i observed is get_elem was not even called and get_next is called twice with the same keypath value(I printed the keypath and its the same for both the times).

Both the times its hitting the same switch case and performing the same set of actions(I verified this by running GDB).

I have no clue as on why its stopped after the second iteration and why its sending -1 in next.

4

As mentioned above, it is completely normal that get_next() is invoked 2x with input parameter next==-1. ConfD can do it once to check whether e.g. list is not empty, and then 2nd time to start iterating the list.

You can verify whether something went wrong when displaying data in ConfD devel.log or confd.err log.

The iteration of list should not stop, assuming you did not send -1 as a next output parameter to ConfD.
(unless other error makes it stop… - some ERR should be stated in devel.log/confd_err.log)