<html><body>
<p><font size="2" face="sans-serif">Duncan,</font><br>
<br>
<font size="2" face="sans-serif">Thanks for the reply. The sorting is done in the common sqlalchemy.utils.paginate_query function, which takes an ORM model class as an argument (<a href="https://github.com/openstack/oslo-incubator/blob/master/openstack/common/db/sqlalchemy/utils.py#L82">https://github.com/openstack/oslo-incubator/blob/master/openstack/common/db/sqlalchemy/utils.py#L82</a>). The only valid sort columns are attributes on the given model class. For example,</font><br>
<br>
<font size="2" face="sans-serif">In cinder that class is "models.Volume": <a href="https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/api.py#L1331">https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/api.py#L1331</a></font><br>
<font size="2" face="sans-serif">In nova that class is "models.Instance": <a href="https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1946">https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1946</a></font><br>
<font size="2" face="sans-serif">In glance that class is "models.Image"; <a href="https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/api.py#L540">https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/api.py#L540</a></font><br>
<br>
<font size="2" face="sans-serif">This limits the scope of what can be sorted on (ie, it cannot be any attribute that exists on an item returned from a detailed query).</font><br>
<br>
<font size="2" face="sans-serif">The blueprint is lacking this level of detail and I will update it accordingly.</font><br>
<br>
<font size="2" face="sans-serif">Does this address your concern?</font><br>
<br>
<font size="2" face="sans-serif">Thanks,</font><br>
<font size="2" face="sans-serif">Steven Kaufer</font><br>
<br>
<tt><font size="2">Duncan Thomas <duncan.thomas@gmail.com> wrote on 04/03/2014 05:18:47 AM:<br>
<br>
> From: Duncan Thomas <duncan.thomas@gmail.com></font></tt><br>
<tt><font size="2">> To: "OpenStack Development Mailing List (not for usage questions)" <br>
> <openstack-dev@lists.openstack.org>, </font></tt><br>
<tt><font size="2">> Date: 04/03/2014 05:25 AM</font></tt><br>
<tt><font size="2">> Subject: Re: [openstack-dev] Support for multiple sort keys and sort<br>
> directions in REST GET APIs</font></tt><br>
<tt><font size="2">> <br>
> Some of the cinder APIs do weird database joins and double lookups and<br>
> things, making every field sortable might have some serious database<br>
> performance impact and open up a DoS attack. Will need more<br>
> investigation to be sure.<br>
> <br>
> On 2 April 2014 19:42, Steven Kaufer <kaufer@us.ibm.com> wrote:<br>
> > I have proposed blueprints in both nova and cinder for supporting multiple<br>
> > sort keys and sort directions for the GET APIs (servers and volumes). I am<br>
> > trying to get feedback from other projects in order to have a more uniform<br>
> > API across services.<br>
> ><br>
> > Problem description from nova proposal:<br>
> ><br>
> > "There is no support for retrieving server data in a specific order, it is<br>
> > defaulted to descending sort order by the "created date" and "id" keys. In<br>
> > order to retrieve data in any sort order and direction, the REST APIs need<br>
> > to accept multiple sort keys and directions.<br>
> ><br>
> > Use Case: A UI that displays a table with only the page of data that it has<br>
> > retrieved from the server. The items in this table need to be sorted by<br>
> > status first and by display name second. In order to retrieve data in this<br>
> > order, the APIs must accept multiple sort keys/directions."<br>
> ><br>
> > See nova proposal .rst file (cinder is basically the same) for more<br>
> > information: <a href="https://review.openstack.org/#/c/84451/">https://review.openstack.org/#/c/84451/</a><br>
> ><br>
> > Most projects have similar GET requests and I am trying to get some<br>
> > consensus on this approach across the various projects; the goal is to have<br>
> > this type of functionality common across projects (not just nova and<br>
> > cinder). Note that some projects (ie, cinder) already support a single sort<br>
> > key and sort direction, see<br>
> > <a href="https://github.com/openstack/cinder/blob/master/cinder/api/v2/">https://github.com/openstack/cinder/blob/master/cinder/api/v2/</a><br>
> volumes.py#L212-L213<br>
> ><br>
> > Note that the DB layer already accepts multiple sort keys and sort<br>
> > directions (see<br>
> > <a href="https://github.com/openstack/oslo-incubator/blob/master/openstack/">https://github.com/openstack/oslo-incubator/blob/master/openstack/</a><br>
> common/db/sqlalchemy/utils.py#L62),<br>
> > the work I am describing here only exposes the sorting options at the REST<br>
> > API layer.<br>
> ><br>
> > Please provide feedback on this direction. Specifically, do you see any<br>
> > issues (and, if so, why) with allowing the caller to specify sort orders and<br>
> > directions on the GET APIs?<br>
> ><br>
> > Feel free to leave your feedback in the Gerrit review for the novablueprint<br>
> > or reply to this thread.<br>
> ><br>
> > Thanks,<br>
> ><br>
> > Steven Kaufer<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > OpenStack-dev@lists.openstack.org<br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> <br>
> <br>
> <br>
> -- <br>
> Duncan Thomas<br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
</font></tt></body></html>