<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:906964255;
mso-list-type:hybrid;
mso-list-template-ids:-40884756 -2113871598 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:\F0D8;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Guang<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Dolph Mathews [mailto:dolph.mathews@gmail.com] <br><b>Sent:</b> Monday, August 12, 2013 8:22 PM<br><b>To:</b> OpenStack Development Mailing List<br><b>Subject:</b> Re: [openstack-dev] [keystone] Pagination<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Mon, Aug 12, 2013 at 7:51 PM, Jamie Lennox <<a href="mailto:jlennox@redhat.com" target="_blank">jlennox@redhat.com</a>> wrote:<o:p></o:p></p><p class=MsoNormal>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).<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If the client is forced to understand the pagination interface then the abstraction is broken.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal>If we standardize on the<br>page/per_page combination<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>There doesn't need to be a "standard."<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal>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.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Correct. This sort of "default" pagination can be implemented by the manager, and overridden by a specific driver.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal><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?<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Rhetorical: why not index from -1 and count in base 64? This is all arbitrary and can vary by driver.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal><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<o:p></o:p></p></div></div><div><div><p class=MsoNormal>> _______________________________________________<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><o:p></o:p></p></div></div></blockquote></div><p class=MsoNormal><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-Dolph <o:p></o:p></p></div></div></div></div></body></html>