cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <>
Subject RE: Should we have separate "Count" API?
Date Mon, 05 Nov 2012 23:56:59 GMT
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 []
> Sent: Monday, November 05, 2012 3:44 PM
> To:; 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 <<>>
> Reply-To: "<mailto:cloudstack-
>>" <cloudstack-
> To: "<mailto:cloudstack-
>>" <cloudstack-
> 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

View raw message