• Deebster@programming.dev
    link
    fedilink
    English
    arrow-up
    11
    ·
    3 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
      ·
      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.

  • Justin@lemmy.jlh.name
    link
    fedilink
    arrow-up
    5
    ·
    3 months ago

    Pretty useful article! I’m pretty sure I’ve seen data shifting happen a few times on Jerboa.

    I wonder if uuid7 based pagination solves these issues. Precise enough that you don’t overlap/over fetch data with time based pagination, while still being essentially time based so you have a consistent offset. Definitely important to limit the size if requests, though.

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

      Probably not; I’d expect the places where you need something like UUIDv7 (large, eventually-consistent systems) to not be entirely suitable because you can have records added out of sequence. You’d have to add a received-at field - but in that case you may as well just use a standard incrementing ID as your primary key.

    • Jade@programming.devOP
      link
      fedilink
      arrow-up
      5
      ·
      3 months ago

      This whole article was sprung from a discussion of exactly that case, because users often simply don’t delete notifications. It’s very common for users to have years of undismissed notifications stacked up under the notification bell, and it’s not a good experience to load them all at once.