• Deebster@programming.dev
    link
    fedilink
    English
    arrow-up
    15
    ·
    2 months ago

    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.

    • Jade@programming.devOP
      link
      fedilink
      arrow-up
      1
      ·
      2 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.