Open Stack

Passing the query parameters, whatever they are, into the driver if the
given driver supports pagination and allowing the driver to override the
manager default pagination functionality seem reasonable to me.

 

 

Guang

 

 

From: Dolph Mathews [mailto:dolph.mathews at gmail.com] 
Sent: Monday, August 12, 2013 8:22 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] Pagination

 

 

On Mon, Aug 12, 2013 at 7:51 PM, Jamie Lennox <jlennox at redhat.com> wrote:

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).

 

I think you're missing the point (and you're right: that wouldn't make sense
at all). The API client follows links. The controller builds links. The
driver defines it's own pagination interface to build related links.

 

If the client is forced to understand the pagination interface then the
abstraction is broken.

 

If we standardize on the
page/per_page combination

 

There doesn't need to be a "standard."

 

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.

 

Correct. This sort of "default" pagination can be implemented by the
manager, and overridden by a specific driver.

 


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?

 

Rhetorical: why not index from -1 and count in base 64? This is all
arbitrary and can vary by driver.

 


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




_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





 

-- 

 

-Dolph 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130813/24b5d5d5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6186 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130813/24b5d5d5/attachment.bin>