I see that whenever we want to send a json REST message towards confD then get_elem is called first.
In case I have a PUT operation that I want to replace existing data, then this functionalty is not working with external DB since get_elem returns an entry back (the value was already contained) and as a result PUT operation fails. PUT or POST operations succeed only if get_elem do not return an entry !
This was not present when using CDB ! How do we overcome this issue ?
Just a small addition in order to explain the problem a bit more.
When we send a GET request the get_elem() function in java is in READ mode
and since there is an element in the external DB the not NULL value is not a
problem. When we try to update the data in a list the get-elem is called
with READ_WRiTE mode and then this is a problem since the not null value is
causing confD to retur a 400 error back. That’s why consider this as an
error from confD. The mode must not be read_write in this case. Unless there
is a way to differentiate PUT, GET, DELETE operation !
If you believe you have found a problem with ConfD it’s better to file an RT-ticket with our support team.
I don’t whether it is an error from our side or from confD.
So let’s re-phrase it…
If we already have data stored in our external DB and a PUT operation is issued for updating the values… Then our get_elem() implementation will return back a ConfValue object. Does it make sense for the PUT operation to fail and confD return back 400 error instead of continuing and updating the data through the call of set_elem() function ?
.
No it doesn’t, it’s best to file a ticket.
Yes, if the exist check fail due to a data provider error, e.g. you have enableAttributes set to true in confd.conf but have not implemented the get_attr() callback, the transaction will fail.
When ConfD check if the value exists to determine if it needs to be written or not, and a data provider error occur, the transaction will fail. If the write operation was done over RESTCONF the operation will fail with “400 Bad Request” and you will see the cause of the error in the ConfD developer log.
This was the issue. Whenever we use YANG model with annotations then we MUST implement get_attrs() function for some validity/existence issues
This is not a correct description - there may be cases where annotations (I assume that you mean use of “tailf:xxx” extensions - the attributes requested by get_attrs() are not modeled in YANG) affect whether get_attrs() is actually invoked, but the requirement for its implementation is stated in the confd_lib_dp(3) manual page:
This callback only needs to be implemented for callpoints specified
for configuration data, and only if attributes are enabled in the
ConfD configuration (/confdConfig/enableAttributes set to true).
Thus in the specified case you need to implement it, in other cases you do not - and in all cases regardless of annotations.