Skip to content
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

Preliminary pagination support API #61

Merged
merged 3 commits into from Jan 10, 2018
Merged

Preliminary pagination support API #61

merged 3 commits into from Jan 10, 2018

Conversation

yakky
Copy link
Member

@yakky yakky commented Dec 30, 2017

This implements support for pagination
Fix #59

By default list method retrieves all the objects navigating the pages returned by the API
all argument allows to disable pagination and return all the results (implementing current behavior)
lazy_pagination argument allows to load a single page

docs/index.rst Outdated
@@ -169,6 +169,27 @@ You can also specify filters

tasks = api.tasks.list(project=1)

By defaults list returns all objects, eventually getting the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/By defaults/By default,/

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, fixed

docs/index.rst Outdated

.. code:: python

tasks_page_1 = api.tasks.list(lazy_pagination) # Will only return page 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add example to get everything

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a plain api.tasks.list() will still return all the results, like it does now, but using the pagination to get all the results

@yakky
Copy link
Member Author

yakky commented Dec 30, 2017

@erikw thanks for your feedback. Does it look a sane API to you?

@yakky
Copy link
Member Author

yakky commented Dec 30, 2017

@erikw I added the page_size argument to allow improved control over the page size (and hence performance)

@erikw
Copy link
Contributor

erikw commented Dec 30, 2017

@yakky I was thinking it was a bit confusing with the different combinations you can make with all and lazy_pagination, but it's needed if we want to support all use cases I guess.

Maybe a matrix in the documentation like this one could help?

all lazy_pagination Output
False False ...
False True ...
True False ...
True True ...

or possible reduce the number of use cases to support to maybe only have one input variable (with page number var too) paginated=True|False?

@erikw
Copy link
Contributor

erikw commented Dec 30, 2017

@yakky Looks good! I was thinking it was a bit confusing though with the different combinations you can make with all and lazy_pagination, but it's needed if we want to support all use cases I guess.

Maybe a matrix in the documentation like this one could help?

all lazy_pagination Output
False False ...
False True ...
True False ...
True True ...

or possible reduce the number of use cases to support to maybe only have one input variable (with page number var too) paginated=True|False?

@yakky
Copy link
Member Author

yakky commented Dec 30, 2017

@erikw thanks for your feedback.

We can use a 3-state argument (let's call it pagination), in addition to page argument to retrieve a specific page but I am worried it might be confusing:

pagination page Output
True (default) None All results retrieved by using paginated results and loading them behind the scenes
True (default) <integer> Only results for the given page are retrieved
False unused Current behavior: all results, ignoring pagination
<integer> None All results retrieved by using paginated results and loading them behind the scenes, using given page size (higher page size could yield better performances)
<integer> <integer> Only results for the given page of the given size are retrieved

@erikw
Copy link
Contributor

erikw commented Dec 30, 2017

@yakky I agree, mixing types even for the same variable is not good. As long as it's clear or alternatively documented what will happen for which values of the argument, it's all good :)

@yakky
Copy link
Member Author

yakky commented Dec 30, 2017

@erikw how about this signature (basically merges all and lazy_pagination)

pagination page_size page Output
True (default) <integer> (default: 100; non numeric values fallbacks to the default) None All results retrieved by using paginated results and loading them behind the scenes, using given page size (higher page size could yield better performances)
True (default) <integer> (default: 100) <integer> Only results for the given page of the given size are retrieved
False unused unused Current behavior: all results, ignoring pagination

@yakky
Copy link
Member Author

yakky commented Dec 30, 2017

@fmarco could you also give a look at this plz?

@erikw
Copy link
Contributor

erikw commented Dec 30, 2017

@yakky this last one looks sounder to me!

@yakky
Copy link
Member Author

yakky commented Dec 30, 2017

Thanks @erikw we will complete this with some tests in the next days and we'll likely release a new version sometimes next week

docs/index.rst Outdated

tasks = api.tasks.list(paginate=False)

.. warning:: be aware that if the unpaginated results may exceed

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove if?

remote objects are retrieved and appended in a single list.

If pagination is disabled, all the objects are fetched from the
endpojnt and returned. This may trigger some parsing error if the

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

endpoint

Copy link

@fmarco fmarco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yakky except for @carloratm's comments, lgtm

@yakky
Copy link
Member Author

yakky commented Jan 5, 2018

Thanks y'all. I'll fix those and I'll implement the tests for this. Hopefully we will be able to merge this and release a new version

@yakky
Copy link
Member Author

yakky commented Jan 7, 2018

@carloratm @fmarco could you have a look at the tests?

@codecov
Copy link

codecov bot commented Jan 7, 2018

Codecov Report

❗ No coverage uploaded for pull request base (master@012fb19). Click here to learn what that means.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff            @@
##             master      #61   +/-   ##
=========================================
  Coverage          ?   99.21%           
=========================================
  Files             ?        8           
  Lines             ?      896           
  Branches          ?        0           
=========================================
  Hits              ?      889           
  Misses            ?        7           
  Partials          ?        0
Impacted Files Coverage Δ
taiga/requestmaker.py 98.33% <100%> (ø)
taiga/models/base.py 99.28% <100%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 012fb19...499534f. Read the comment docs.

@yakky yakky merged commit 618cb2a into master Jan 10, 2018
@erikw
Copy link
Contributor

erikw commented Jan 10, 2018

Awesome!

When can we expect a new release of python-taiga that includes this?

@yakky
Copy link
Member Author

yakky commented Jan 10, 2018

@erikw with a bit of luck within the weekend 🤞

@erikw
Copy link
Contributor

erikw commented Jan 28, 2018

@yakky or maybe this weekend? :) 🙏

@yakky
Copy link
Member Author

yakky commented Jan 28, 2018

@erikw early next week 🙇 (but 0.9rc1 is already on PyPi)
0.9 will likely be identical

@yakky
Copy link
Member Author

yakky commented Jan 30, 2018

@erikw 0.9.0 released!

@erikw
Copy link
Contributor

erikw commented Feb 2, 2018

@yakky Many thanks!

I've now updated my project https://github.com/erikw/taiga-stats to use this release :)

@yakky
Copy link
Member Author

yakky commented Feb 3, 2018

Nice tool!
Do you mind adding a comment here #67 to list it?
I would like to start a section of tools and libraries using python-taiga to help people discovery nice stuff

@erikw
Copy link
Contributor

erikw commented Feb 3, 2018

Good idea!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants