I like the "countOnly" idea. If it were a proper REST API, it would be GET /vm/count?state=Running And GET /vm?state=Running
On 11/5/12 4:03 PM, "Min Chen" <min.c...@citrix.com> wrote: >Thanks Alena. Maybe we should support a query parameter "countOnly" or >something for count only case to avoid issuing extra sql queries. > >-min > >From: Alena Prokharchyk ><alena.prokharc...@citrix.com<mailto:alena.prokharc...@citrix.com>> >Date: Monday, November 5, 2012 3:43 PM >To: >"cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apach >e.org>" ><cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apach >e.org>>, Min Chen <min.c...@citrix.com<mailto:min.c...@citrix.com>> >Subject: Re: Should we have separate "Count" API? > >Min, > >We didn't use separate call as well as didn't use resource count table >because we "count" field represents the number of DB resources matching >the search criteria (ignoring page/pageSize info) specified in the list* >api call. For example: > >listVirtualMachines&state=Running&hostId=1&page=1&pageSize=1 > >In the "count" field we expect to see the only how many vms in Running >state, running on hostId=1 exist in the system; not the entire number of >vms in the system that we keep per account in resource_count table. >And although only one vm object will be returned (as you requested >page=1&pageSize=1), you'll know how many vms in the system satisfy the >search criteria. > >As variation of parameters depends on particular API call, the count has >to be returned as a part of list* command response. > >-Alena. > >From: Min Chen <min.c...@citrix.com<mailto:min.c...@citrix.com>> >Reply-To: >"cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apach >e.org>" ><cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apach >e.org>> >To: >"cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apach >e.org>" ><cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apach >e.org>> >Subject: Should we have separate "Count" API? > >Hi there, > >In fixing the bug regarding count of a list API today, I cannot help >wondering why we cannot have separate "Count" api for such purpose rather >than bundling this information with list API, where we basically return >some information that some users will just throw away since they only >care about count for dashboard purpose. I also noticed that in our DB >schema, we actually have a table "resource_count" there, not sure the >original rational behind this table. If we can take advantage of this >table (and keep the information there up-to-date), we may be able to >provide a very efficient way to implement such "Count' apis for most >commonly used cases. >Any thoughts on this? > >Thanks >-min >
