Bug 1558114 - [RFE] Support /count API for owner pools
Summary: [RFE] Support /count API for owner pools
Alias: None
Product: Candlepin
Classification: Community
Component: candlepin
Version: 2.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Barnaby Court
QA Contact: Katello QA List
Depends On:
Blocks: 1560054
TreeView+ depends on / blocked
Reported: 2018-03-19 16:27 UTC by Jonathon Turel
Modified: 2018-04-06 15:08 UTC (History)
3 users (show)

Fixed In Version: candlepin-2.3.5-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1560054 (view as bug list)
Last Closed: 2018-04-06 15:08:33 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github candlepin candlepin pull 1943 0 None None None 2018-03-22 18:42:29 UTC

Description Jonathon Turel 2018-03-19 16:27:06 UTC
Description of problem:

We need a way to retrieve the total # of pools for an owner to support paging of upstream/portal subscriptions in the UI. Retrieving the total # by way of minimizing includes is not sufficient (too slow).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

No such API exists

Expected results:

There exists an API: GET /owners/{owner_key}/pools/count which returns the total number of pools which respects the current filtering 

Additional info: GET /owners/:owner_id/consumers/count is a similar API that already exists

IT will need the version containing this API to support our work

Comment 1 Barnaby Court 2018-03-19 17:43:41 UTC
After discussions with Brad, it would be acceptable to provide the maximum number of records as metadata when the first page of data is returned.

Comment 2 Barnaby Court 2018-03-22 14:55:17 UTC
Currently we provide a link header that does have some useful information and could be used as a workaround. However, it would be better to include the total # of items as a value. 

Link: <https://localhost:8443/candlepin/owners/foo/pools?include=id&page=1&per_page=5&include=id&per_page=5&page=2>; rel="next", <https://localhost:8443/candlepin/owners/foo/pools?include=id&page=1&per_page=5&include=id&per_page=5&page=1>; rel="first", <https://localhost:8443/candlepin/owners/foo/pools?include=id&page=1&per_page=5&include=id&per_page=5&page=200>; rel="last"

Comment 3 Barnaby Court 2018-03-22 14:59:59 UTC
A http header of "X-total-count" with the total number of records would be very helpful if paging is used.

Comment 4 Jonathon Turel 2018-03-23 14:27:24 UTC
I looked into using the link header. My approach was using ?page=1&per_page=1 in my query. In theory the last page should be the total number. It was still slow enough to make paging an unpleasant experience when there are many pools. I had about 3k pool and the response was over 3 seconds, so we won't be going that route as a workaround.

In addition to the "x-total-count" header, it will be nice to have an "x-subtotal-count" header which reflects the number of results according to any filtering applied.

Comment 5 Jonathon Turel 2018-03-23 17:51:24 UTC

Per our in-person chat I spoke with Walden regarding handling subtotals. He told me that the x-total-count header reflecting the total after filtering applied is fine - so we can forget about adding the subtotal header I proposed.

Note You need to log in before you can comment on or make changes to this bug.