Why get_next is called when both get_next and get_next_object are defined when printing full table entries?

CDB and CDB API
1

I executed following CLI table,

user@host> show arpentries arpe
IP           IFNAME  HWADDR             PERMANENT  PUBLISHED
--------------------------------------------------------------
172.16.1.1   eth0    fa:16:3e:5b:ad:2c  false      false
172.16.1.10  eth0    fa:16:3e:ff:c6:24  false      false

[ok][2019-04-25 07:40:18]

Following is trace:
TRACE CALL data get_next(thandle=7, /arpentries/arpe, -1) --> CONFD_OK TRACE CALL data get_next_object(thandle=7, /arpentries/arpe, -1) --> CONFD_OK TRACE CALL data get_next_object(thandle=7, /arpentries/arpe, 0) --> CONFD_OK

I have registered both get_next and get_next_object
data.get_elem = get_elem;
data.get_next = get_next;
data.get_next_object = get_next_object;
strcpy(data.callpoint, arpe__callpointid_arpe);

Question is:
Why both get_next and get_next_object is being called when table is queried?

All data required to be displayed for operational CLI can be obtained from get_next_object.
So why get_next is being called?

Is there any way I can suppress first get_next being called?

Reason for asking,
We are doing some cleanup/allocation when we get “-1” as “next” value. Since “-1” is passed twice, double cleanup/allocation happens.

3

This is most probably invoked internally for ConfD as an existence check / check whether any data is present in the list before further processing…
IMHO you cannot disable it explicitly - maybe other callbacks like .num_instances() can be added to be invoked instead of get_next() by ConfD if it makes your situation easier (i haven’t tested myself if it works this way).

4

Thanks for reply.
Exposing num_instances didn’t help. Still get_next was called.

5

Any other thoughts?

Is it safe to assume that get_next will always be called before calling get_next_object? Based on some experiments, it looks like that.
So that I do memory allocation only in get_next (when next = -1) and ignore memory allocation for get_next_object.

6

We used to have the same issue. If we do not register get_next_object() then confd would invoke get_next() twice with next = -1. In first next = -1 call, we used to place the malloced data in tctx->t_opaque (otherwise NULL before this). And then this t_opaque data is propagated to next get_next() or get_next_object() calls. We avoided allocation there by checking if t_opaque is already non-NULL.

1 Like