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.prokharc...@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.c...@citrix.com<mailto:min.c...@citrix.com>> > Reply-To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack- > d...@incubator.apache.org>" <cloudstack- > d...@incubator.apache.org<mailto:cloudstack-dev@incubator.apache.org>> > To: "cloudstack-dev@incubator.apache.org<mailto:cloudstack- > d...@incubator.apache.org>" <cloudstack- > d...@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
