In fact, I think we should always do that. We should always have a flag that allows the server to behave in backward compatibility mode and one that works the way it's supposed to work. New deployments will want to constrict it to new behavior. The tweet Dave sent out is basically sent because we didn't offer the backward compatibility.
--Alex > -----Original Message----- > From: Will Chan [mailto:will.c...@citrix.com] > Sent: Thursday, December 27, 2012 2:05 PM > To: cloudstack-...@incubator.apache.org > Cc: cloudstack-users@incubator.apache.org > Subject: RE: [VOTE] Enforcing UUID string in API query > > 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-...@incubator.apache.org > > Cc: cloudstack-users@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-...@incubator.apache.org > > > Cc: cloudstack-users@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. > > >
