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