Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
The creation of this issue has been discussed in #736.
Ideas about pagination have been discussed in #718. It seems were are basically 4 options :
Even though offset/limit is clearly the most straightforward API, I do tend to agree that the anchor-item approach is the most future-scalable. Perhaps the methods can be made to accept either a full Model instance (wherein we will look up the necessary fields for constructing the inequality in the WHERE clause) or an ID (which will cause an extra query to first look up the Model).
Of course, we will also need a (slow) alternative for slow (in-Python) queries. It won't be too hard to just skip over all rows before the anchor item is seen.
I am so not an expert in this area, though. Folks with more experience writing web apps, for example, probably have better opinions than I do.
Sorry guys, I'm not sure if I'm barking up the wrong tree here, and please tell me to get lost, but from a UI perspective, pagination or pager navigation isn't the most user friendly interface to have to use - we've done a lot of usability testing and found that they're not as straightforward as we'd like to think. You'd be surprised at the types of feedback, which I can share if you need me to.
A lot of the stuff mentioned here goes right over my head, but after reading #738, it seems like pagers/paged navigation methods will play a part in the proposed UI implementations. Can we reconsider their use and look at alternative options before making a decision - like I said, in terms of UI. Many thanks.