Regarding type "union" support in data providing API

Core Engine and APIs
1

Hi,

We are working on a prototype to store config data in external database than CDB.
As type union is not supported in API, any work around or solution to support union?

Thanks & Regards,
Azeem

2

Please, can you describe what kind of API do you have in mind? External CDB API uses callbacks from struct confd_data_cbs. Is there any restriction on union type?

3

Hi,

We are going to use external database API(confd_dp.h) with callpoints.

Thanks & Regards,
Azeem

4

Type union is of course supported in the APIs, it’s just that it doesn’t have its own confd_value_t representation, i.e. you will never get or set a value with the C_UNION confd_vtype enum. Instead the confd_value_t type is whichever of the union member types that the current value has.

5

Hi,

I am aware of what you have mentioned.

In our implementation we use the type information from 'confd_cs_node_info* while storing and retrieving value from the external database(to map the confd types with external database types). While storing union value, I can manage by storing as a string in the database.

But after retrieving I need to convert into appropriate type and reply using “confd_data_reply…” function.
My problem is I cannot know the type of the union so that I can convert into appropriate type and reply.

Thanks & Regards,
Azeem

6

hello,

as the external DB API is used to “represent” data/information stored outside of ConfD, you need to be able to tell what is type of union data in the external source as well…

e.g. you may need to add extra info to your encoding process when saving data towards external DB, to be able to utilize it when reading the data from external db to send to confd…

(when saving data, you need to persist not only value of the data being stored, but also it’s type)

b.r.
joseph

7

Hi,

Yes, I think this is the only option available.
Thanks for your help.

Regards,
Azeem

8

Well, if you store the value as a string in the external DB, another possibility is to convert it to confd_value_t by using confd_str2val() when returning it to ConfD - this of course assumes that the string form is consistent with the lexical representation per the YANG spec (e.g. a string produced by confd_val2str()). Yet another possibility is to use the CONFD_DAEMON_FLAG_STRINGSONLY “daemon flag”, in which case your data provider will receive, and is expected to return, all values as strings (C_BUF/C_STR). But Joseph’s suggestion may be preferable.

9

Hi,

Thanks for providing me this valuable information, I will look into it.

Regards,
Azeem

10

Hi,

In continuation to the same problem, I have one more question.
The type information that will come for union from confd_cs_node_info is actual type(int8, double, ipv4 …), how can I distinguish that it is from the node which has type union. If adapter(daemon) that we are going to have is generic adapter(common for all nodes/models with different types) to store config data from confd to external database?

By anyway, I can find in the daemon that the node has a type union and the value store is of type int, double, ipv4 etc?

Hope I am clear in explaining the problem.

Thanks & Regards,
Azeem

11

The confd_cs_node_info struct gives you two different things:
enum confd_vtype shallow_type;
This will be C_INT8 etc for non-union types, but C_UNION for a union type.
struct confd_type *type;
This pointer can be used with confd_val2str()/confd_str2val() for both union and non-union types.

confd_value_t values that you receive in set_elem(), and return from get_elem(), will always have C_INT8 etc types, never C_UNION. But you can lookup the confd_cs_node_info struct for the leaf and learn that it is a union from shallow_type == C_UNION.

Does that help?

12

Hi,

Yes, I think I can use this information to implement union.
Thanks for your support; I will try to implement this.

Thanks & Regards,
Azeem