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. 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. >>> >
