Leaf name for operational data

[JamesZhang]

Hi,
I notice that DP provider callback function receives xmltag value for leaf data node as follow, is it possible to pass the leaf name down to callback function instead of xmltag value? or is there the way to translate xmltag value back to leaf name in callback function?

/*
    path:     /port{<slot> <port>}/<leaf>
    kp index:  2    1              0
*/
static int get_elem(struct confd_trans_ctx *tctx,
                    confd_hkeypath_t *keypath)
{
    int8_t slot = CONFD_GET_INT8(&keypath->v[1][0]);
    int8_t port = CONFD_GET_INT8(&keypath->v[1][1]);
    int32_t leaf = CONFD_GET_XMLTAG(&keypath->v[0][0]); <---
    int pos = get_entry(slot, port);
    confd_value_t v;
   ...

thanks for assistance

[cohult]

Hi,

If you have done, like most ConfD examples do, a maapi_load_schemas() or confd_load_schemas() (see confd_lib_maapi(3) manual page), information for all namespaces loaded into ConfD is then made available.

In your get_elem() callback you can then for example do something like:

struct confd_cs_node *csp;
char *name;
csp = confd_find_cs_node(keypath, keypath->len);
name = confd_hash2str(csp->tag);
fprintf(stderr, "\nNode name: %s\n", name);

See confd_types(3) manual page, section USING SCHEMA INFORMATION for more.

If we put the above into the examples.confd/intro/5-c_stats example and do a show arpentries we get something like this in the libconfd trace mixed with the printf from the dataprovider application:

TRACE Connected (maapi) to ConfD
TRACE MAAPI_LOAD_ALL_NS
TRACE MAAPI_LOAD_HASH_DB
TRACE Connected (dp) to ConfD
TRACE Received daemon id 0
TRACE Connected (dp) to ConfD
TRACE Picked up old user session: 11 for user:system ctx:system
TRACE Picked up old user session: 10 for user:system ctx:system
TRACE Picked up old user session: 1 for user:system ctx:system
TRACE New user session: 12 for user:admin ctx:cli --> CONFD_OK
TRACE CALL trans init(thandle=7,mode="r",db=running) --> CONFD_OK
TRACE CALL data get_next(thandle=7, /arpentries/arpe, -1) --> CONFD_OK
TRACE CALL data get_next(thandle=7, /arpentries/arpe, -1) --> CONFD_OK
TRACE CALL data get_elem(thandle=7,/arpentries/arpe{192.168.1.1 en0}/hwaddr)
Node name: hwaddr
 ("a:36:dd:dd:66:f6")  --> CONFD_OK
TRACE CALL data get_elem(thandle=7,/arpentries/arpe{192.168.1.1 en0}/permanent)
Node name: permanent
 (true)  --> CONFD_OK
TRACE CALL data get_elem(thandle=7,/arpentries/arpe{192.168.1.1 en0}/published)
Node name: published
 (false)  --> CONFD_OK
TRACE CALL data get_next(thandle=7, /arpentries/arpe, 140385450983952) --> CONFD_OK
TRACE CALL data get_elem(thandle=7,/arpentries/arpe{10.0.0.1 en0}/hwaddr)
Node name: hwaddr
 ("2:0:5d:aa:1:1")  --> CONFD_OK
TRACE CALL data get_elem(thandle=7,/arpentries/arpe{10.0.0.1 en0}/permanent)
Node name: permanent
 (true)  --> CONFD_OK
TRACE CALL data get_elem(thandle=7,/arpentries/arpe{10.0.0.1 en0}/published)
Node name: published
 (false)  --> CONFD_OK
TRACE CALL data get_next(thandle=7, /arpentries/arpe, 140385450984016) --> CONFD_OK
TRACE CALL data get_elem(thandle=7,/arpentries/arpe{10.0.0.251 en0}/hwaddr)
Node name: hwaddr
 ("1:0:5e:1:1:fb")  --> CONFD_OK
TRACE CALL data get_elem(thandle=7,/arpentries/arpe{10.0.0.251 en0}/permanent)
Node name: permanent
 (true)  --> CONFD_OK
TRACE CALL data get_elem(thandle=7,/arpentries/arpe{10.0.0.251 en0}/published)
Node name: published
 (false)  --> CONFD_OK
TRACE CALL data get_next(thandle=7, /arpentries/arpe, 0) --> CONFD_OK

[JamesZhang]

Thanks, Cohult, it is quite useful.
just asking - I notice macro CONFD_DAEMON_FLAG_STRINGSONLY of function confd_set_daemon_flags, is it an alternative as well for DP proxy daemon?
Anyway, thanks for helping on this.

[cohult]

Quoting @per from a topic related to your question:

@per

I can see that using string values instead of the ConfD-specific “internal values” can make sense in some scenarios (and for a data provider you can actually have ConfD do it for you, by using the CONFD_DAEMON_FLAG_STRINGSONLY flag with confd_init_daemon()). But turning the hkeypaths into strings, and then having to parse the result and do string compares to figure out which part of the data model is referenced, instead of just switch()ing on the integer hash values, doesn’t seem like an obviously good idea to me…

(There is a reason that hkeypaths are used ConfD -> application, and “string paths” in the other direction - hkeypaths are simple to analyze but difficult to construct, while “string paths” are difficult to analyze but simple to construct. ConfD does all the hard work in order to make the application writer’s job easier.:-))

[per]

@cohult

struct confd_cs_node *csp;
char *name;
csp = confd_find_cs_node(keypath, keypath->len);
name = confd_hash2str(csp->tag);
fprintf(stderr, “\nNode name: %s\n”, name);

This is fine, and the way to go when you want the full schema information for the leaf, e.g. to be able to reliably convert the value of the leaf to a string via confd_val2str(). But if you only want the name of the leaf, it’s actually enough (and a bit more efficient) to do:

char *name = confd_hash2str(CONFD_GET_XMLTAG(&keypath->v[0][0]));
fprintf(stderr, "\nNode name: %s\n", name);

[JamesZhang]

Thanks for helping