Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130812/a36f7688/attachment.html>