Hi Rohit, I didn't understand the rationale behind this. Can you please explain ? thanks
On 28-Dec-2012, at 5:12 AM, Rohit Yadav wrote: > Alright, spoke with tsp on irc on testing methods etc. I fixed [1] the > apiserver to make it backward compatible; > > - For all pre 3.x apis, both uuid, internal id can be used, all pre 3.x apis > don't have since field in their annotation. > - For post 3.x apis, uuid param checking is enforced. > Can you please explain me the relation with 3.x api's ? I guess what Will said that all the objects (resources) created pre 3.x will have just ID populated and not the UUID. Also I saw the code and there is regex check for UUID. I am afraid that will impact the performance. > The response (xml or json) always had uuid (and not internal id) since 3.x > which is fine with everyone and I fail to understand the case. > > [1] > https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=623e7389ef0b2923b7859629cd70406e2e471525 > > Regards. > > On 27-Dec-2012, at 2:04 PM, Will Chan <will.c...@citrix.com> wrote: > >> I personally do not like flags changing syntax which is what it is in this >> case. A flag to support whether a feature like "snapshots" is supported is >> ok. A flag to say whether ID or UUID is accepted means issues with >> backwards compatibility and also the fact that both ways needs to be tested >> and validated. >> >> Will >> >>> -----Original Message----- >>> From: Alex Huang [mailto:alex.hu...@citrix.com] >>> Sent: Thursday, December 27, 2012 12:44 PM >>> To: cloudstack-dev@incubator.apache.org >>> Cc: cloudstack-us...@incubator.apache.org >>> Subject: RE: [VOTE] Enforcing UUID string in API query >>> >>> Sorry I don't understand why it needs to be a vote. Why can't we just offer >>> a flag to turn it on and off? >>> >>> --Alex >>> >>>> -----Original Message----- >>>> From: Rohit Yadav [mailto:rohit.ya...@citrix.com] >>>> Sent: Thursday, December 27, 2012 12:11 PM >>>> To: cloudstack-dev@incubator.apache.org >>>> Cc: cloudstack-us...@incubator.apache.org >>>> Subject: [VOTE] Enforcing UUID string in API query >>>> >>>> Hi, >>>> >>>> I'm asking for the community to vote if they want to enforce UUID >>>> string to be used in parameters while querying an API. This would >>>> break any client or script that uses internal ID. AFAIK api response >>>> (json or xml, since 3.x for sure) always have had UUIDs so if any >>>> client/script that uses apis to query entities and base their further >>>> operations using ids from the response(s) should be fine. >>>> >>>> You may vote by: >>>> +1 Agree >>>> 0 No opinion >>>> -1 Disagree >>>> >>>> Some context and description: >>>> >>>> CloudStack uses internal IDs which are long ints and they have a >>>> mapping between this ID and the external ID or UUID which is a random >>>> string of characters. >>>> There are DAO classes which provides a mechanism to query a particular >>>> table(s) and do other operations. There are VO objects which can hold >>>> content of a row. In most VO objects a method getId() would return a >>>> long int number which is the internal ID of that entity and they would >>>> have a >>>> getUuid() which returns a unique random string of chars. >>>> >>>> At present an API can be queried with both ids, for example for param >>>> domainid using uuid in 1 and using id in 2: >>>> >>>> 1. >>>> >>> http://localhost:8080/client?command=listResourceLimits&domainid=866 >>> 4e >>>> 0 >>>> 4a-9931-4765-b3456e6888d0fa1d >>>> 2. >>> http://localhost:8080/client?command=listResourceLimits&domainid=1 >>>> >>>> For querying using id, the caller should have idea of the id for that >>>> entity and which is only possible if they have access to CloudStack's >>>> database. There is no other way of knowing an entity's id, only uuids >>>> are sent as ids in the response. >>>> >>>> Regards. >>>> >> >
