Open CallMeBW opened 3 years ago
There is a _fetch_pages()
function that is called in most functions including jira.sprints
. Which I think aims to do what you are describing. Have you noticed this not working as intended? Perhaps there is a bug in that function itself.
https://github.com/pycontribs/jira/blob/eb80088cd0da1d27043a2d457f2f045725ef97f0/jira/client.py#L576-L601
Doesn't necessarily mean we shouldn't implement this Pager
class, but it may allow it to be integrated better into existing functions.
Although _fetch_pages
does handled paginated routes, it doesn't return a generator. So what happens is it retrieves all the results one page at a time and then it returns all the results in memory to the caller. Instead, it would be more efficient when working with a large number of issues, to yield a generator with 1 page of results at a time.
Is this really working though?
When running search issues it returns _fetch_pages
so the returned list should be complete. However clearly it does not match itself.
issues = jira.search_issues('project = myproject', maxResults=1000)
issue_data = []
for issue in issues:
issue_data.append(issue)
print(issues.total) #513
print(len(issue_data)) #100
Update:
Actually there seems to be a bug with maxResults
as returned object maxResults
is set to 100
.
If I set maxResults=False
or None
, then it works as expected. Quite unintuitive I must say.
@MSKDom would be great if you can raise this behaviour in a new issue to track it better. I am unable to pick it up at this time, but perhaps another contributor (or even yourself) can further investigate a solution to this behaviour.
I created a new issue for this in #1819
Many of the JIRA resources come with a pagination approach. The initial request returns only a chunk of data. The developer has to take care of retrieving all results by incresaing the
startAt
parameter. Besides producing boilerplate code, this is a potential source of errors, as it requires to keep track of the last index returned etc.If the Jira Wrapper came with a pagination functionality, it would be more convenient to work with the API. For example, to retrieve all sprints should be a one-liner. I would like to propose a class that takes a generic jira function and provides a function that accumulates all results.
The above class could furthermore be extended to provide a function that returns a continuous iterator. This iterator would iterate over all results, and when the end of a page is reached, the next request with adapted
startAt
will be called. However, I haven't included it yet, as it would not be transparent to the user as of which call to__next__()
would trigger the longer loading time.Here is an example how to use the Pager class to retrieve all active sprints: