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
When paging limits would allow for more items, but they run out, items can still be requested directly. Though their "next" attribute is None. Setting an arbitrarily large offset doesn't affect the call, so this cannot happen the other way around, except in search. So search paging limits function a bit differently. Like ordinary calls, items beyond the total may be requested. But the offset of search items is limited to 5000. The following raises 404 - Not Found on "next".
There are a few situations where this can arise. And in each one we can try and return None if the call fails, or let it fail. I think we should try to base them on the behavior of other paging calls.
Direct call to search: other calls return a paging result with empty items, next: None and previous: link. I think we should let the error be raised, test it and document its existence.
Getting next page: other calls paging results have the next as None. Search should catch the error and return None as the others.
Getting all pages or items: other calls end when next is None. Search should too, through next.
So I'm proposing we should handle it in paging navigation, but let the error be raised in the direct call. Thoughts?
The text was updated successfully, but these errors were encountered:
When paging limits would allow for more items, but they run out, items can still be requested directly. Though their "next" attribute is None. Setting an arbitrarily large offset doesn't affect the call, so this cannot happen the other way around, except in search. So search paging limits function a bit differently. Like ordinary calls, items beyond the total may be requested. But the offset of search items is limited to 5000. The following raises 404 - Not Found on "next".
There are a few situations where this can arise. And in each one we can try and return None if the call fails, or let it fail. I think we should try to base them on the behavior of other paging calls.
next: None
andprevious: link
. I think we should let the error be raised, test it and document its existence.next
.So I'm proposing we should handle it in paging navigation, but let the error be raised in the direct call. Thoughts?
The text was updated successfully, but these errors were encountered: