Open Stack

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/20130812/7a8d8b76/attachment.html>