Stephen Mike is right, it is mostly (possibly only?) extensions that do double lookups. Your plan looks sensible, and definitely useful. I guess I'll see if I can actually break it once the review is up :-) I mostly wanted to give a heads-up - there are people who are way better at reviewing this than me.
On 3 April 2014 19:15, Mike Perez <[email protected]> wrote: > Duncan, I think the point you raise could happen even without this change. In > the example of listing volumes, you would first query for the list in some > multi-key sort. The API extensions for example that add additional response > keys will do another lookup on that resource for the appropriate column it's > retrieving. There are some extensions that still do this unfortunately, but > quite a few got taken care of in Havana in using cache instead of doing these > wasteful lookups. > > Overall Steven, I think this change is useful, especially from one of the > Horizon sessions I heard in Hong Kong for filtering/sorting. > > -- > Mike Perez > > On 11:18 Thu 03 Apr , Duncan Thomas wrote: >> Some of the cinder APIs do weird database joins and double lookups and >> things, making every field sortable might have some serious database >> performance impact and open up a DoS attack. Will need more >> investigation to be sure. >> >> On 2 April 2014 19:42, Steven Kaufer <[email protected]> wrote: >> > I have proposed blueprints in both nova and cinder for supporting multiple >> > sort keys and sort directions for the GET APIs (servers and volumes). I am >> > trying to get feedback from other projects in order to have a more uniform >> > API across services. > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
