Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Edison.su@citrix.com designates
 66.165.176.63 as permitted sender)
From: Edison Su <Edison.su@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>, Min Chen <min.chen@citrix.com>
Date: Mon, 5 Nov 2012 15:56:59 -0800
Subject: RE: Should we have separate "Count" API?
Thread-Topic: Should we have separate "Count" API?
Thread-Index: Ac27r01cAepkkOAJSGaHUB5X6RkwbQAAYesQ
Message-ID: 
 <C66C814C1ABFA8449FF65CB44953A8B4012CBD6F7E12@SJCPMAILBOX01.citrite.net>
References: <CCBD8BCE.16CC%min.chen@citrix.com>
 <CCBD8DCE.19328%alena.prokharchyk@citrix.com>
In-Reply-To: <CCBD8DCE.19328%alena.prokharchyk@citrix.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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 pyth=
on 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?
>=20
> Min,
>=20
> We didn't use separate call as well as didn't use resource count table be=
cause
> we "count" field represents the number of DB resources matching the searc=
h
> criteria (ignoring page/pageSize info) specified in the list* api call. F=
or
> example:
>=20
> listVirtualMachines&state=3DRunning&hostId=3D1&page=3D1&pageSize=3D1
>=20
> In the "count" field we expect to see the only how many vms in Running
> state, running on hostId=3D1 exist in the system; not the entire number o=
f 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=3D1&pageSize=3D1), you'll know how many vms in the system satisfy th=
e
> search criteria.
>=20
> As variation of parameters depends on particular API call, the count has =
to be
> returned as a part of list* command response.
>=20
> -Alena.
>=20
> 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?
>=20
> Hi there,
>=20
> In fixing the bug regarding count of a list API today, I cannot help wond=
ering
> 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 abo=
ut
> count for dashboard purpose. I also noticed that in our DB schema, we
> actually have a table "resource_count" there, not sure the original ratio=
nal
> 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?
>=20
> Thanks
> -min