-
-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some solution is needed for controlled paging #43
Comments
I can try to work on a solution some time next week, but honestly I can't think of anything satisfactory without introducing either
What are your thoughts? |
Sounds like you want to handle this outside of How about allowing |
I'm not against That consideration notwithstanding, there's only one thing needed for controlled pagination -- three for complete control: where to start returning results. IIRC, this is usually controlled by the
For the first piece -- the |
I missed an option -- it is possible (though a duplication of work across clients) to keep track of which page of each resource was last retrieved. That should be possible to do at the ghub+ level, at which point I'd probably opt for cl-structs (blech!). Unless there's a better way to do it, of course. Magit will eventually have this problem, too, since many repositories maintain >30 open PRs: |
Does the graphql api also return paginated results? |
It does, but it's a little different. GraphQL has a concept of a cursor that it prefers over other methods. Wondering what you're thinking, here -- as far as ghub is concerned, v4 GraphQL is accessed the same way as v3 REST (I'm pretty sure); see |
While setting a dynamic variable would be an easy fix, I don't think it's the right thing to do -- especially with the impending advent of multithreaded elisp. |
I have just pushed better unpaginating support and later today I will probably push support for asynchronous requests, which will improve unpaginating further. (length (ghub-get "/users/tarsius/repos"))
(length (ghub-get "/users/tarsius/repos" '((per_page . 100))))
(length (ghub-get "/users/tarsius/repos" nil :unpaginate t))
(length (ghub-get "/users/tarsius/repos" '((per_page . 4)) :unpaginate t))
(length (ghub-get "/users/tarsius/repos" '((per_page . 4)) :unpaginate 3)) Asynchronous requests will allow controlled unpaginating without the need for global state. (ghub-get "/users/tarsius/repos" nil
:unpaginate t
:callback (lambda (value _headers _status _args)
(setq my-value value)))
(ghub-get "/users/tarsius/repos" nil
:callback (lambda (value _headers _status args)
(unless (ghub-continue args)
(setq my-value value)))) These two forms are basically equivalent, but the second could be extended to only unpaginate if some condition is met (most likely if not too much time has passed already). |
thanks!! |
The
unpaginate
argument is the idealized behavior of any API request, but it's often inappropriate when working with very large repositories with many hundreds (perhaps even thousands) of objects. In these cases, it's a better user experience to actually page the results.Related vermiculus/magithub#152.
The text was updated successfully, but these errors were encountered: