-1 - Agree with Will on this. Matt Mullins
On 12/27/12 3:45 PM, "Will Chan" <will.c...@citrix.com> wrote: >-1 > >You will end up breaking anyone that has written any scripts/plugins/apps >on top of pre 3.x CS. Since UUID was introduced in 3.0, you should only >accept the following: > >- All first class objects created before 3.0 should accept an normal >internal ID. >- All first class objects created after 3.0 should accept UUID only. Any >attempts to query these objects using the internal ID should result in >"object not found". > >By forcing everything to take in a UUID means you will have to force many >of CS's integration on top of pre 3.0 CS to re-map their internal IDs. >This is just not practical. > >Will > >> -----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 >> 4e04a-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. >> >
