In the /api/v2/logs call, the “total” property currently returns the total number of logs matching the query parameters.
We rely on this value for pagination.
There is an upcoming breaking change in which “total” will no longer provide this information. The breaking changes guidance says, “please update your [pagination] logic to handle this change appropriately.”
Do you have any high level suggestions as to how to manage pagination without this value? Without it, there doesn’t seem to be any way to determine how many pages of logs might be available to view.
For instance, there doesn’t seem to be a “next” token or “more results” flag that would at least indicate that there are more results to get. That would at least enable us to render a “next page” link.
What are other folks doing here?
1 Like
Without the total you will not indeed be able to estimate the exact number of pages so you will need to consider an approach where if you want to show 20 items per page then your request asks for 21, you render only 20 in the user interface and if there’s one more in the current result set then it means there’s a next page you can request.
Thank you for the suggestion. That will at least enable us to show a “next” link.
It’s a shame to go backwards on this functionality. For companies like us with a standard approach to pagination, we’re now going to have to make an exception for Auth0 user logs.
3 Likes
Thanks a lot for that feedback @jgaines! I’ll make sure to relay it to appropriate team!
if you want to show 20 items per page then your request asks for 21, you render only 20 in the user interface
When trying to use this approach, I’ve run into a problem where the second page will then retrieve logs 22-42. Because we keep asking the endpoint for 21 items every page, it assumes the second page starts at 22, the third page at 43 etc. If we skip the display of the 21st item on the first page, the 21st item will then never be shown.
Example with page size of 21 and only showing 20 in the UI
First page: User Logs 1-21 of which we show 1-20
Second page: User Logs 22-42 of which we show 22-41
Third page: User Logs 43-63 of which we show 43-62
As you can see in the above example, items 21, 42 and 63 will never be shown in the UI.
I can’t think of a way around this to show whether or not there is another page other than doing an additional request for the next page for every page request, doubling requests to the Auth0 API.
To me, this does not seem like a solid enough solution to use. If you do have a way around this, I would be happy to know.
May I ask why paging without an overall total has been chosen in v3 without any other alternative to provide sufficient paging information to the consumer?
It was an implementation decision for which I personally don’t have full information about, but it’s likely related to performance. The cost of calculating the entire set available for a search may be significant so this would be an optimization.
Also, I could likely have provided a more detailed response about the approach I mentioned. With the +1 approach the client will have to be a bit more mindful of the parameters being used. In particular, the first page will start at zero and the second page will still need to start at 20 and not 21 (for the 20 per page example). However, the client will have to know to request one more in order to use that as a signal even though it cannot start the second page at that index.
With the above you’re still getting some data more than once, but it does not incur the penalty of multiple network calls.
Removing the total is madness. It completely breaks any UI that relies on it. Such as ng-bootstrap tables. Tables rely on knowing the total so it can determine how many pages there are based on the chosen page size, then render the controls appropriately. This breaks that.