cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@citrix.com>
Subject Fwd: [MERGE] Merge request: api_refactoring on master
Date Wed, 09 Jan 2013 22:40:11 GMT
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 as 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 succeeds 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 built by GenericDaoBase (see methods by same names) and we expect
only one row or result as uuid and id is unique.

2. For API introduced in 3.x and above using the since tag in the @APICommand (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 annotation 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 which 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 performing well now, due to db views you
don't have 10 or n queries for n entities, Min can talk more about the implementation and
how it speeds up the listing 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 and 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=3079 OR uuid='3079'"
type calls for every VM we have when doing listVirtualMachines and such?

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message