2 ms·
Sure, that's why I'm asking whether this is at all common. If the use case is programmatic, then just provide the ability to get an arbitrarily large set atomic
by lhorie 6y ago
Sure, that's why I'm asking whether this is at all common. If the use case is programmatic, then just provide the ability to get an arbitrarily large set atomically (rather than forcing pagination size limits) and the problem goes away.
Another thing to consider when paginating via id cursors: if the deleted item is the one your cursor is sitting on, then you no longer have a frame of reference at all. For example, what happens to commit history pagination in github's implementation if I rewrite git history? Chibicc for example deliberately rewrites its history for didactic purposes.
- ngrilly 6y ago> just provide the ability to get an arbitrarily large set atomically It's difficult to do in most HTTP deployments where we try to limit HTTP response duration. > if the deleted item is the one your cursor is sitting on, then you no longer have a frame of reference at all Not a problem. If your order your results by timestamp and ID, then you provide the timestamp and ID of the last item returned, and take anything after. Doesn't matter if the item is still there or not.
- lhorie 6y agoNot sure what you mean by timestamp, but I don't think that works for the example I posted. If I rewrite the first commit in history, every single entry will have different sha's and commit dates. With offsets, clicking "next" will at best feel like nothing happened, or at worst run into the mild off-by-one confusion. With ids, there's no way for the system to know where to go unless there's custom logic to somehow map old sha's to the new ones (assuming that is even possible).