Project

Profile

Help

Story #5324

As a Pulp3 user, I have Limit/Offset style pagination as my default

Added by bmbouter 8 months ago. Updated 4 months ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

100%

Platform Release:
Blocks Release:
Backwards Incompatible:
No
Groomed:
Yes
Sprint Candidate:
Yes
Tags:
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:

Description

Currently the default is PageId pagination. This was discussed some on this mailing list thread: https://www.redhat.com/archives/pulp-dev/2019-August/msg00025.html

Design

In the settings.py switch the default to LimitOffsetPagination.

Details

1. Remove IDPagination

2. Update the DEFAULT_PAGINATION_CLASSdefault in settings.py to the LimitOffsetPagination example from the DRF docs

Associated revisions

Revision d34076e6 View on GitHub
Added by bmbouter 7 months ago

Switch Pagination default to LimitOffset Style

The previous pagination was Page ID style and used a custom class from Pulp to do so. This switches the default pagination class to a limit offset style by default instead.

https://pulp.plan.io/issues/5324 closes #5324

History

#1 Updated by daviddavis 8 months ago

A few questions. Should the pagination style be configurable? I'd say no for now (but we can address when a stakeholder needs it to be).

Should limit and offset be required and if not what should the default values be? For default values, of course 0 makes sense for offset.

For limit, I think we should go as small as possible because some resources might be quite large. Also, API users probably want smaller sizes while integrated apps (galaxy, katello, etc) prefer larger sizes. Since it's easier for machines to specify a limit, I think a smaller limit makes sense. I'd say 20 or 50.

#2 Updated by bmbouter 7 months ago

  • Description updated (diff)

daviddavis wrote:

A few questions. Should the pagination style be configurable? I'd say no for now (but we can address when a stakeholder needs it to be).

It would be challenging for Pulp to prevent this configuration in the sense that DRF looks for its settings in the django file and we couldn't stop users from customizing it. We could manually override this on every model, or through the ancestor classes and then the default wouldn't apply, but I'm not in favor of that.

I see it as a good thing that users can configure this because it reinforces the idea that "Pulp is just plain DRF". I think we need to communicate to users that changing these would break the published bindings and they could rebuild them locally.

Should limit and offset be required and if not what should the default values be? For default values of course 0 makes sense for offset. For limit, I think we should go as small as possible because some resources might be quite large. Also, API users probably want smaller sizes while integrated apps (galaxy, katello, etc) prefer larger and since it's easier for machines to specify a limit. I think a smaller limit makes sense, I'd say 20 or 50.

I agree. At least one integrator wanted a default page size limit so I'm +1 on that. https://www.redhat.com/archives/pulp-dev/2019-August/msg00030.html

I think offset=0 by default so we can probably not specify that one. We currently have a page size of 100 here

Do we want to change the page size?

#3 Updated by daviddavis 7 months ago

Keeping the page size at 100 is fine with me.

#4 Updated by daviddavis 7 months ago

  • Groomed changed from No to Yes
  • Sprint Candidate changed from No to Yes

#5 Updated by bmbouter 7 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to bmbouter

With no objects raised on the mailing list, and the need to switch this soon, I'm taking as assigned.

#6 Updated by bmbouter 7 months ago

  • Description updated (diff)

#7 Updated by bmbouter 7 months ago

  • Status changed from ASSIGNED to POST

#8 Updated by bmbouter 7 months ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100

#9 Updated by bmbouter 4 months ago

  • Sprint/Milestone set to 3.0.0

#10 Updated by bmbouter 4 months ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Also available in: Atom PDF