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