Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A8C94DFCA for ; Tue, 6 Nov 2012 00:15:32 +0000 (UTC) Received: (qmail 70634 invoked by uid 500); 6 Nov 2012 00:15:32 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 70603 invoked by uid 500); 6 Nov 2012 00:15:32 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 70595 invoked by uid 99); 6 Nov 2012 00:15:32 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Nov 2012 00:15:32 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Alena.Prokharchyk@citrix.com designates 66.165.176.89 as permitted sender) Received: from [66.165.176.89] (HELO SMTP.CITRIX.COM) (66.165.176.89) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Nov 2012 00:15:27 +0000 X-IronPort-AV: E=Sophos;i="4.80,718,1344211200"; d="scan'208";a="43522446" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 06 Nov 2012 00:15:06 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Mon, 5 Nov 2012 16:15:05 -0800 From: Alena Prokharchyk To: Chiradeep Vittal , CloudStack DeveloperList Date: Mon, 5 Nov 2012 16:15:45 -0800 Subject: Re: Should we have separate "Count" API? Thread-Topic: Should we have separate "Count" API? Thread-Index: Ac27s8VB89Xlu2GCS6CEfRToK9tJRQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Good idea.=20 As a workaround for now, you can call listVms&page=3D1&pageSize=3D0&state=3DRunning. Zero objects will be returned, but "count" will be present in the response showing how many running vms you have. -Alena. On 11/5/12 4:12 PM, "Chiradeep Vittal" wrote: >I like the "countOnly" idea. If it were a proper REST API, it would be >GET /vm/count?state=3DRunning >And >GET /vm?state=3DRunning > >On 11/5/12 4:03 PM, "Min Chen" 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 >>> >>Date: Monday, November 5, 2012 3:43 PM >>To:=20 >>"cloudstack-dev@incubator.apache.org>h >>e.org>"=20 >>>h >>e.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=3DRunning&hostId=3D1&page=3D1&pageSize=3D1 >> >>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. >> >>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:=20 >>"cloudstack-dev@incubator.apache.org>h >>e.org>"=20 >>>h >>e.org>> >>To:=20 >>"cloudstack-dev@incubator.apache.org>h >>e.org>"=20 >>>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 >> > >