On 27-Dec-2012, at 12:44 PM, Alex Huang <alex.hu...@citrix.com> wrote:
> 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? This needs to be voted because I knew something was not right and the FS kept emphasising that UUIDs to be accepted. I knew it would break backward compatibility with some scripts/clients. I raised this in several emails before, but only now I can see some guidance. I'm not going to enable a global settings flag, we can implement something that Will suggests; allow both ID and UUIDs, some cmd classes are annotated with a *since* field which holds the version since the api was introduced, this can be used to enforce UUID param translation. The implementation is different and processing is done via annotations in ApiDispatcher, so overloading of functions and other ideas don't apply. Thanks all for your comments. Regards. > > --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=8664e0 >> 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. >> >
