[openstack-dev] [keystone] Pagination

Jamie Lennox jlennox at redhat.com
Tue Aug 13 00:51:23 UTC 2013


I'm not sure where it would make sense within the API to return the name
of the page/per_page variables to the client that doesn't involve having
already issued the call (ie returning the names within the links box
means you've already issued the query). If we standardize on the
page/per_page combination then this can be handled at the controller
level then the driver has permission to simply ignore it - or have the
controller do the slicing after the driver has returned.

To weigh in on the other question i think it should be checked that page
is an integer, unless per_page is specified in which case default to 1.

For example: 

GET /v3/users?page=

I would expect to return all users as page is not set. However: 

GET /v3/users?per_page=30

As per_page is useless without a page i think we can default to page=1.

As an aside are we indexing from 1?

On Mon, 2013-08-12 at 19:05 -0500, Dolph Mathews wrote:
> The way paginated links are defined by the v3 API (via `next` and
> `previous` links), it can be completely up to the driver as to what
> the query parameters look like. So, the client shouldn't have (nor
> require) any knowledge of how to build query parameters for
> pagination. It just needs to follow the links it's given.
> 
> 
> 'page' and 'per_page' are trivial for the controller to implement (as
> it's just slicing into an list... as shown)... so that's a reasonable
> default behavior (for when a driver does not support pagination).
> However, if the underlying driver DOES support pagination, it should
> provide a way for the controller to ask for the query parameters
> required to specify the next/previous links (so, one driver could
> return `marker` and `limit` parameters while another only exposes the
> `page` number, but not quantity `per_page`).
> 
> 
> On Mon, Aug 12, 2013 at 4:34 PM, Henry Nash
> <henryn at linux.vnet.ibm.com> wrote:
>         Hi
>         
>         
>         I'm working on extending the pagination into the backends.
>          Right now, we handle the pagination in the v3 controller
>         class....and in fact it is disabled right now and we return
>         the whole list irrespective of whether page/per-page is set in
>         the query string, e.g.:
>         
>         
>             def paginate(cls, context, refs):
>                 """Paginates a list of references by page & per_page
>         query strings."""
>                 # FIXME(dolph): client needs to support pagination
>         first
>                 return refs
>         
>         
>                 page = context['query_string'].get('page', 1)
>                 per_page = context['query_string'].get('per_page', 30)
>                 return refs[per_page * (page - 1):per_page * page]
>         
>         
>         I wonder both for the V3 controller (which still needs to
>         handle pagination for backends that do not support it) and the
>         backends that do....whether we could use wether 'page' is
>         defined in the query-string as an indicator as to whether we
>         should paginate or not?  That way clients who can handle it
>         can ask for it, those that don'twill just get everything.  
>         
>         
>         Henry
>         
>         
> 
> 
> 
> 
> -- 
> 
> 
> -Dolph
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






More information about the OpenStack-dev mailing list