Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

p 8, sec 3.1.5. The "offset" Query Parameter #36

Open
flycoolman opened this issue Dec 24, 2024 · 0 comments
Open

p 8, sec 3.1.5. The "offset" Query Parameter #36

flycoolman opened this issue Dec 24, 2024 · 0 comments

Comments

@flycoolman
Copy link
Contributor

(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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant