<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 12, 2013 at 7:51 PM, Jamie Lennox <span dir="ltr"><<a href="mailto:jlennox@redhat.com" target="_blank">jlennox@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not sure where it would make sense within the API to return the name<br>
of the page/per_page variables to the client that doesn't involve having<br>
already issued the call (ie returning the names within the links box<br>
means you've already issued the query).</blockquote><div><br></div><div>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.</div>
<div><br></div><div>If the client is forced to understand the pagination interface then the abstraction is broken.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If we standardize on the<br>
page/per_page combination</blockquote><div><br></div><div>There doesn't need to be a "standard."</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
then this can be handled at the controller<br>
level then the driver has permission to simply ignore it - or have the<br>
controller do the slicing after the driver has returned.<br></blockquote><div><br></div><div>Correct. This sort of "default" pagination can be implemented by the manager, and overridden by a specific driver.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To weigh in on the other question i think it should be checked that page<br>
is an integer, unless per_page is specified in which case default to 1.<br>
<br>
For example:<br>
<br>
GET /v3/users?page=<br>
<br>
I would expect to return all users as page is not set. However:<br>
<br>
GET /v3/users?per_page=30<br>
<br>
As per_page is useless without a page i think we can default to page=1.<br>
<br>
As an aside are we indexing from 1?<br></blockquote><div><br></div><div>Rhetorical: why not index from -1 and count in base 64? This is all arbitrary and can vary by driver.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On Mon, 2013-08-12 at 19:05 -0500, Dolph Mathews wrote:<br>
> The way paginated links are defined by the v3 API (via `next` and<br>
> `previous` links), it can be completely up to the driver as to what<br>
> the query parameters look like. So, the client shouldn't have (nor<br>
> require) any knowledge of how to build query parameters for<br>
> pagination. It just needs to follow the links it's given.<br>
><br>
><br>
> 'page' and 'per_page' are trivial for the controller to implement (as<br>
> it's just slicing into an list... as shown)... so that's a reasonable<br>
> default behavior (for when a driver does not support pagination).<br>
> However, if the underlying driver DOES support pagination, it should<br>
> provide a way for the controller to ask for the query parameters<br>
> required to specify the next/previous links (so, one driver could<br>
> return `marker` and `limit` parameters while another only exposes the<br>
> `page` number, but not quantity `per_page`).<br>
><br>
><br>
> On Mon, Aug 12, 2013 at 4:34 PM, Henry Nash<br>
> <<a href="mailto:henryn@linux.vnet.ibm.com">henryn@linux.vnet.ibm.com</a>> wrote:<br>
> Hi<br>
><br>
><br>
> I'm working on extending the pagination into the backends.<br>
> Right now, we handle the pagination in the v3 controller<br>
> class....and in fact it is disabled right now and we return<br>
> the whole list irrespective of whether page/per-page is set in<br>
> the query string, e.g.:<br>
><br>
><br>
> def paginate(cls, context, refs):<br>
> """Paginates a list of references by page & per_page<br>
> query strings."""<br>
> # FIXME(dolph): client needs to support pagination<br>
> first<br>
> return refs<br>
><br>
><br>
> page = context['query_string'].get('page', 1)<br>
> per_page = context['query_string'].get('per_page', 30)<br>
> return refs[per_page * (page - 1):per_page * page]<br>
><br>
><br>
> I wonder both for the V3 controller (which still needs to<br>
> handle pagination for backends that do not support it) and the<br>
> backends that do....whether we could use wether 'page' is<br>
> defined in the query-string as an indicator as to whether we<br>
> should paginate or not? That way clients who can handle it<br>
> can ask for it, those that don'twill just get everything.<br>
><br>
><br>
> Henry<br>
><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
><br>
><br>
> -Dolph<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>