Getting a container data or how to show it without get_elem one after the other

CDB and CDB API
1

I have a container x with “n” leaf elements.

Able to show that. But this is getting fetched using get_elem which gets called recursively.
Is it possible to give as get_object.

Tried to redefine the container as a list with max-elements=1 and no key.
Thought of using get_next() — return NULL for next=0 does not help.

when next=-1, confd_data_reply_next_key(tctx, NULL, -1, 0); /* No Key /
when next=0, confd_data_reply_next_key(tctx, NULL, -1, -1); / End of List */

Any help to get the container elements in one go (without multiple get_elem()) ?

2

Lists with no keys are described in ConfD user guide - “Operational data lists without keys”.
There actually is a hidden key, and you should return some value (artificial number) instead of NULL in your get_next() response.
Then you can implement get_object() in usual way… (or you can go directly with get_next_object() to save an extra IPC communication of separate get_next()/get_object() invocations)

3

True, but if @aruns17 actually has, and wants to have, a container, in current versions of ConfD the CONFD_DAEMON_FLAG_BULK_GET_CONTAINER can be passed to confd_set_daemon_flags() to indicate that the data provider is prepared to handle get_object() for a container in certain cases, as described in the confd_lib_dp(3) man page.

1 Like
4

If get_object() is not implemented for a container and it is ok to have get_elem() ?
Dont want to cause regression on the existing configuration/clis.

5

Well, in the current implementation, even if your daemon uses the CONFD_DAEMON_FLAG_BULK_GET_CONTAINER flag, it actually has no effect if get_object() isn’t implemented. But there is no point in using the flag if you don’t implement get_object(), and the documentation says “This flag tells ConfD that the data provider is prepared to handle a get_object() callback invocation for…”

6

Hm, but maybe I misunderstood your question about “get_object() is not implemented for a container”. From ConfD’s point of view, you implement get_object() - or not - for a callpoint. I.e. if you have implemented get_object() for a given callpoint, and used the flag, and the callpoint covers leafs that are candidates for get_object()-for-container invocation as described in the man page, get_object() may be invoked for the container, even if the actual callback code can’t handle that. ConfD obviously has no way of knowing what your code can do - the point of the flag is to allow you to tell ConfD about it.