Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of rohit.yadav@citrix.com
 designates 203.166.19.134 as permitted sender)
From: Rohit Yadav <rohit.yadav@citrix.com>
To: Min Chen <min.chen@citrix.com>
CC: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Thu, 10 Jan 2013 04:10:11 +0530
Subject: Fwd: [MERGE] Merge request: api_refactoring on master
Thread-Topic: [MERGE] Merge request: api_refactoring on master
Thread-Index: Ac3uukqpddYIw9BPRJeznhnT/VO8JQ==
Message-ID: <920FB93F-BECA-495C-8B07-CB8A46160E60@citrix.com>
References: 
 <0BCCCE152323764BB7FD6AE6D7A1D9060102894ED07B@BANPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_920FB93FBECA495C8B07CB8A46160E60citrixcom_"
MIME-Version: 1.0

--_000_920FB93FBECA495C8B07CB8A46160E60citrixcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Fwd, +Min, +cs-dev

Begin forwarded message:

From: Rohit Yadav <rohit.yadav@citrix.com<mailto:rohit.yadav@citrix.com>>
Subject: RE: [MERGE] Merge request: api_refactoring on master
Date: 9 January 2013 11:36:47 AM PST
To: Marcus Sorensen <shadowsor@gmail.com<mailto:shadowsor@gmail.com>>

No, so this change will first of all check the kind of input param we got a=
s part of the api request and call getUuid() for:

1. If the API is Pre 3.x (since tag is empty), first we try to convert the =
string to long int (only after checking against the uuid regex), if that su=
cceeds we getById( this accepts long int id we just parsed), else if regex =
suggests that it's uuid, we getByUuid(). In both cases a search query is bu=
ilt by GenericDaoBase (see methods by same names) and we expect only one ro=
w or result as uuid and id is unique.

2. For API introduced in 3.x and above using the since tag in the @APIComma=
nd (previously @Implementation), we only check getUuid() and do the same as=
 above.

In the change we don't get the table info from the @IdentityMapper (this an=
notation had previously defined the table name as string within the cmd api=
 class), we get it through links via the response and the entity referred w=
hich end up to a VO class which has the @Table name.

Coming back to your question, so the above change applies only when a id is=
 passed, when just listing vms or for any list apis, we are actually perfor=
ming well now, due to db views you don't have 10 or n queries for n entitie=
s, Min can talk more about the implementation and how it speeds up the list=
ing apis.

Regards.
________________________________________
From: Marcus Sorensen [shadowsor@gmail.com<mailto:shadowsor@gmail.com>]
Sent: Wednesday, January 09, 2013 10:56 PM
To: Rohit Yadav
Subject: Re: [MERGE] Merge request: api_refactoring on master

- Remove IdentityMapper and IdentityProxy
- Fix api param processing and uuid/id translation. Pre 3.x apis (all apis =
except those which has their @APICommand annotation's "since" field set to =
3.xx or 4.xx) accept both uuids (string) and internal (long int) ids. 3.x a=
nd later apis are enforced to send uuids for api request to succeed.

Does this mean we won't see 10 "SELECT uuid FROM `vm_instance` WHERE id=3D3=
079 OR uuid=3D'3079'" type calls for every VM we have when doing listVirtua=
lMachines and such?

Min and community, the above question and answer, just fyi.

--_000_920FB93FBECA495C8B07CB8A46160E60citrixcom_--