Configure default requests with per_page=100 #145

Closed
ptwobrussell opened this Issue Mar 9, 2013 · 6 comments

Projects

None yet

3 participants

@ptwobrussell

Per http://developer.github.com/v3/#pagination, the max items that can possibly be requested is 100 as opposed to the default of 30. From what I can tell, the default is used in all requests and there's no way to override it without modifying the source. Hence, about 1/3 of the available data is being returned on lots of requests

Is there a reason not to go ahead and add a default per_page=100 to all API requests? Best case, it results in faster access to data, and worst case, it has no effect. For my particular uses, I'm making lots of requests, and a speedup of ~3.3x would be a big help.

Thoughts?

@ptwobrussell

After some more digging around, a quick hack for this to anyone who is interested is to update firstParams in PaginatedList.init with a value of {"per_page" : '100'} in order to get the higher data throughput. Unfortunately, it looks like a lot of code will have to be touched to add this in as a general purpose configuration option because all of the objects that I've peeked at appear to return a PaginatedList with no current way to pass through.

@jacquev6 jacquev6 was assigned Mar 11, 2013
@jacquev6
Member

It will be relatively easy to add this as an option on the Github object and pass it to all PaginatedLists through the Requester object.
It means that all requests returning a PaginatedList will have the same per_page argument. It seams acceptable, but I want to check with you first.

@jacquev6
Member

I can't change the default value, because it may break some programs using PaginatedList.get_page and assuming 30 items per page.

@bilderbuchi

add some function to change the value globally (so that interested parties can change it easily), and milestone the default value change for 2.0? ^.^

@ptwobrussell

@jacquev6 - Makes perfect sense. I think the ability to pass in a parameter to Github would be a great way to make this happen, especially if it's relatively easy to implement.

@jacquev6
Member

I'll do that soon, adding a parameter to the constructor of Github, and a property to change it afterwards.

@jacquev6 jacquev6 closed this Mar 21, 2013
@ptwobrussell ptwobrussell added the v1 label Mar 2, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment