this post was submitted on 19 Aug 2024
74 points (96.2% liked)

Programming

17528 readers
233 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] Deebster 16 points 3 months ago (1 children)

In time-based pagination, the suggested fix to lots of data in a selected timespan is:

simply adding a limit to the amount of records returned (potentially via a query parameter) transparently solves it.

This means clients can't see all the results, unless you add a way to view other pages of data, which is just pagination again. Or is the intended design that clients view either the first x results (the default) or view all results?

The problem with articles like OPs and others is that they don't allow custom sorting, which is often a requirement, e.g. interfaces that present the data in a table, where column headers can be clicked to sort.

[โ€“] JadedBlueEyes 1 points 3 months ago

Regarding your first paragraph, this results limit is per page. To get the next page, you take your timestamp of the last item and use it in from_time, or whatever you've called it. It's still a pagination technique.

Regarding custom sorting, some of the techniques in the article can do this, some of them can't. Obviously timestamp based pagination can't, however the ID-based pagination that I mentioned can.