You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(7) p 8, sec 3.1.5. The "offset" Query Parameter
Allowed Values
The allowed values are unsigned integers. It is an error for the
offset value to exceed the number of entries in the working
result-set, and the "offset-out-of-range" identity SHOULD be
produced in the error-app-tag in the error output when this
occurs.
Conformance
The "offset" query parameter MUST be supported for all lists and
leaf-lists.
Offset may be expensive to implement, if the YANG list is not naturally
backed by an indexed data structure. E.g., foreach query, it is
plausible that the server implementation will either need to cache the
results, or linearly walk the list from 0 for each offset query. If the
list is long and the requested number of entries is small, then this ends
up getting close to O(n^2), performance wise.
Hence, I was wondering whether the solution really needs to be support
both "offset"
and "cursor", given a cursor implementation could just encode/return the
relevant numeric offsets if that was the most efficient representation of
the data structure?
The text was updated successfully, but these errors were encountered:
(7) p 8, sec 3.1.5. The "offset" Query Parameter
Allowed Values
The allowed values are unsigned integers. It is an error for the
offset value to exceed the number of entries in the working
result-set, and the "offset-out-of-range" identity SHOULD be
produced in the error-app-tag in the error output when this
occurs.
Conformance
The "offset" query parameter MUST be supported for all lists and
leaf-lists.
Offset may be expensive to implement, if the YANG list is not naturally
backed by an indexed data structure. E.g., foreach query, it is
plausible that the server implementation will either need to cache the
results, or linearly walk the list from 0 for each offset query. If the
list is long and the requested number of entries is small, then this ends
up getting close to O(n^2), performance wise.
Hence, I was wondering whether the solution really needs to be support
both "offset"
and "cursor", given a cursor implementation could just encode/return the
relevant numeric offsets if that was the most efficient representation of
the data structure?
The text was updated successfully, but these errors were encountered: