cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject Re: [VOTE] Enforcing UUID string in API query
Date Thu, 27 Dec 2012 20:23:29 GMT
Forgot to mention, let's keep the voting period open till 7th Jan 2013 12:00 GMT, i.e. as a
lot of people are offline.

On 27-Dec-2012, at 12:11 PM, Rohit Yadav <> wrote:

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

View raw message