# Is there any CDB equivalent to CONFD\_DAEMON\_FLAG\_STRINGSONLY? **URL:** \ **Category:** CDB and CDB API\ **Created:** [April 2, 2018, 3:23pm UTC](https://dmap-community.ductus.global/t/is-there-any-cdb-equivalent-to-confd-daemon-flag-stringsonly/1859 "2018-04-02T15:23:20Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![rwestphal](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/rwestphal/32/168_2.png) [@rwestphal](https://dmap-community.ductus.global/u/rwestphal)\ **Post date:** [April 2, 2018, 3:23pm UTC](https://dmap-community.ductus.global/t/is-there-any-cdb-equivalent-to-confd-daemon-flag-stringsonly/1859/1 "2018-04-02T15:23:20Z")
Hi, I’m working on an open-source program that needs to support multiple northbound agents, including ConfD. The problem is that different northbound agents encode YANG data in different ways (e.g. ConfD encodes IPv4 addresses using `in_addr` structures whereas other programs encode IPv4 addresses using strings). What I’m trying to do is to normalize all YANG data my program receives into raw strings and then parse this string myself (with the help of `libyang` to identify the YANG type). This is certainly not very efficient but it simplifies things quite a bit for me. Looking at the ConfD documentation I found the `CONFD_DAEMON_FLAG_STRINGSONLY` flag which makes ConfD deliver strings (`C_BUF`) for all YANG types, but unfortunately this flag is only available in the Data Provider API (I’m using CDB). I also tried to use `confd_val2str()` but I found it to be too complicated to use in a generic way (for all possible YANG types). `confd_pp_value()` on the other hand is super convenient but it doesn’t provide the raw YANG data value (e.g. `enum<3>` instead of `3`). One solution I thought about is to write a function to convert a `confd_value` structure to a string myself. It would be similar to `confd_pp_value()` but without the “pretty” part, only the raw value would be printed. This idea however feels like an overkill to solve a simple problem. I’d appreciate if someone could shed some light on what would be the best way to do what I’m trying to do, any suggestion would be welcome. Regards, Renato. ---
**Author:** ![per](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@per](https://dmap-community.ductus.global/u/per)\ **Post date:** [April 5, 2018, 11:02pm UTC](https://dmap-community.ductus.global/t/is-there-any-cdb-equivalent-to-confd-daemon-flag-stringsonly/1859/2 "2018-04-05T23:02:50Z")
> [@rwestphal](#): > > Looking at the ConfD documentation I found the CONFD\_DAEMON\_FLAG\_STRINGSONLY flag which makes ConfD deliver strings (C\_BUF) for all YANG types, but unfortunately this flag is only available in the Data Provider API (I’m using CDB). Correct - and `CONFD_DAEMON_FLAG_STRINGSONLY` predates the possibility to do generic value → string translation in the library via `confd_val2str()` - i.e. if `confd_val2str()` had been first, `CONFD_DAEMON_FLAG_STRINGSONLY` would never have been implemented… > [@rwestphal](#): > > I also tried to use confd\_val2str() but I found it to be too complicated to use in a generic way (for all possible YANG types). The generiic way is to get the `struct confd_type*` from the `struct confd_cs_node*` for the leaf you have a value for, and find the `struct confd_cs_node*` via the path to the leaf. And you “should” always have that path already, either as the “string path” that you passed to e.g. `cdb_get()` (use `confd_cs_node_cd()` to find the node) or as a `confd_hkeypath_t*` that you received in the `iter()` callback for `cdb_diff_iterate()` (use `confd_find_cs_node()` to find the node). It’s basically just 2 lines of code, e.g.: ```auto struct confd_cs_node *csp = confd_cs_node_cd(NULL, path); confd_val2str(csp->info.type, &v, buf, sizeof(buf)); ``` > [@rwestphal](#): > > confd\_pp\_value() on the other hand is super convenient but it doesn’t provide the raw YANG data value (e.g. enum\<3\> instead of 3). It would be quite problematic if it printed “3” - you could have a YANG union of enumeration and e.g. int32, in which case it would be impossible to tell the difference between the 4th enum and the integer 3. (And if you at some point wanted to translate it back to an internal value, it would always be the integer.) > [@rwestphal](#): > > One solution I thought about is to write a function to convert a confd\_value structure to a string myself. It would be similar to confd\_pp\_value() but without the “pretty” part, only the raw value would be printed. This idea however feels like an overkill to solve a simple problem. You _could_ implement something like that fairly trivially by using `confd_serialize()` and then your favorite stringification method on the binary buffer produced - e.g. hex or base64. > [@rwestphal](#): > > I’d appreciate if someone could shed some light on what would be the best way to do what I’m trying to do, any suggestion would be welcome. I would recommend the `confd_val2str()` way. ---
**Author:** ![rwestphal](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/rwestphal/32/168_2.png) [@rwestphal](https://dmap-community.ductus.global/u/rwestphal)\ **Post date:** [April 14, 2018, 8:33pm UTC](https://dmap-community.ductus.global/t/is-there-any-cdb-equivalent-to-confd-daemon-flag-stringsonly/1859/3 "2018-04-14T20:33:58Z")
@per Thanks to your help I’ve managed to use `confd_val2str()` successfully here. For some reason I thought this function was a bit complicated but it turned out to be very easy to use 🙂 However I still think the `CONFD_DAEMON_FLAG_STRINGSONLY` flag is useful as it allows me to send operational data to ConfD using raw strings instead of binary data. Thanks a lot for your detailed reply!