Hi
In 6.3.9, for one of the CLIs, the find_next call back was triggered. Later I have upgraded to 7.3.2, but get_next() call back is getting triggered for the same CLI now instead of find_next() after the upgrade. Even though, I went though the release notes, I couldn’t figure out the reason for this specific change. Could you please help me to understand this behavior change?
As always, you should not assume and hardcode any particular order or a certain data provider callback to be called for some show show command. ConfD will select the data provider callback it believes fit best for the data to be read from the data provider application given the callbacks you have registered. That may change between releases, and especially for the CLI where ConfD besides reading data also has to calculate tab completes and showing tables.
Anyhow, there is no reason to register get_next() when you have registered find_next(). I would suggest you move your get_next() handling to find_next() and remove the get_next() callback from your implementation.
See the ConfD 7.5 examples.confd/dp/generic_perf if you are interested in what the optimal DP setup is for most use cases.
}
leaf leaf2 {
type string;
}
leaf leaf3 {
type uint16;
}
}
For the above yang model. There is difference in find_next behaviour.
There are three keys in the model and we specify two keys to get entire list. It used to work in confd6.3.9.
In 6.3.9 confd version
TRACE CALL data find_next(thandle=53, container1/list1, same_or_next, {leaf1 leaf2}) --> CONFD_DELAYED_RESPONSE
In 7.3.2 confd version
TRACE CALL data find_next(thandle=53, container1/list1, next, {}) --> CONFD_DELAYED_RESPONSE
Could you please give your inputs how to gets keys from in find_next callback
For the find_next() callback, if nkeys == 0 then ConfD is asking for the first list entry.
If your 6.3.9 based implementation did not cover that use case, it didn’t really work. Rather you were lucky.
For the above yang model. There is differenc in find_next behaviour.
There are three keys in the model and we specify two keys to get entire list. It used to work in confd6.3.9.
In 6.3.9 confd version
TRACE CALL data find_next(thandle=53, container1/list1, same_or_next, {leaf1 leaf2}) --> CONFD_DELAYED_RESPONSE
In 7.3.2 confd version
TRACE CALL data find_next(thandle=53, container1/list1, next, {}) --> CONFD_DELAYED_RESPONSE
Could you please give your inputs how to gets keys from in find_next callback