- CountOnly should have it's own API. Putting it as a parameter to the call and have it completely change the semantics of the response doesn't make sense to me. - If we return a count with the list, I agree with what George suggested. The count should actually be in the header. It's more meta information. Now, having a parameter that says turn off the count or turn on the count in addition to the list makes sense.
--Alex -----Original Message----- From: Rohit Yadav [mailto:rohit.ya...@citrix.com] Sent: Tuesday, November 06, 2012 9:25 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Should we have separate "Count" API? countOnly would be better. If the only use of calling the API in that way is to get the count, we may not want the clients (UI and CLI) to go through the extra/overhead parsing and processing of the returned list of objects. Thanks. Regards. On 06-Nov-2012, at 6:08 PM, Nitin Mehta <nitin.me...@citrix.com> wrote: > > > +1 to adding countOnly flag. > > > On 06-Nov-2012, at 7:02 AM, Vijaykumar Natarajan wrote: > >> IMHO, >> >> Instead of a count or countOnly API for each resource type, it'd be >> better to create a stats API which returns counts for all resources >> (no of vms, no of Ips etc.). This is typically the use case (in >> dashboards etc) for which the count is really useful and will avoid >> multiple calls to get all this information. Not averse to the >> suggestion below (which can always exist in addition to the stats API), >> though. >> >> -- Cheers >> Vijay >> > > > I think listAccounts already gives that info for vms, ips, volumes count etc. > belonging to that account. > Thats what the UI also uses to get the count info for a particular account. > > >> On 11/6/12 5:42 AM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> wrote: >> >>> 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@incubato >>>> r.apac >>>> h >>>> e.org>" >>>> <cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubato >>>> r.apac >>>> h >>>> 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@incubato >>>> r.apac >>>> h >>>> e.org>" >>>> <cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubato >>>> r.apac >>>> h >>>> e.org>> >>>> To: >>>> "cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubato >>>> r.apac >>>> h >>>> e.org>" >>>> <cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubato >>>> r.apac >>>> h >>>> 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 >>>> >>> >> >
