cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <jburw...@basho.com>
Subject Re: Should we have separate "Count" API?
Date Tue, 06 Nov 2012 16:24:44 GMT
George,

+1 -- my response exactly.  The HTTP protocol provides the semantic for this type of information
through a HEAD operation.  

Thanks,
-John

On Nov 5, 2012, at 7:02 PM, Jessica Wang <Jessica.Wang@citrix.com> wrote:

> Edison,
> 
> "count" is not referring to how many items in an API response.
> "count" is referring to how many items in database.
> 
> e.g. There are 3500 VMs in database.
> listVirtualMachines API returns 500 VMs each time (by page parameter and pagesize parameter).
> In this case, "count" will be 3500 instead of 500.
> 
> Jessica
> 
> -----Original Message-----
> From: Edison Su [mailto:Edison.su@citrix.com] 
> Sent: Monday, November 05, 2012 3:57 PM
> To: cloudstack-dev@incubator.apache.org; Min Chen
> Subject: RE: Should we have separate "Count" API?
> 
> If we return a list in the list API, e.g. [VM1, VM2, .., VMn], the "count", or the length
of list can be inferred from the list. When I write the python binding for cloudstack API,
I found "count" field is not that usefull.
> 
>> -----Original Message-----
>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>> Sent: Monday, November 05, 2012 3:44 PM
>> To: cloudstack-dev@incubator.apache.org; Min Chen
>> 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.chen@citrix.com<mailto:min.chen@citrix.com>>
>> Reply-To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack-
>> dev@incubator.apache.org>" <cloudstack-
>> dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apache.org>>
>> To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack-
>> dev@incubator.apache.org>" <cloudstack-
>> dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apache.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
> 


Mime
View raw message