Nitin, I don't understand you question, pre 3.x objects, what are those? AKAIK
CloudStack upgrade to 4.1 would have an upgrade path which would populate all
tables with missing UUID fields, this is necessary for response view etc. as
response objects always have uuids. Therefore, all objects will also have UUIDs.
Regex would be much faster and only O(k) (k is max no. of params that have
CommandType UUID and cal. of one field would be only O(1)) as UUID would be 32
char long, than string comparison or splitting/comparision and the blunt way of
throwing the string over Long value conversion will make it not even slow but
will cause exception. Share any fast and secure way? One fast but insecure
method is to try converting the string to long and if it fails assume it was
regex:
try {
internalId = Long.parseLong(uuid);
} catch(NumberFormatException e) {
// In case regex failed, and it's still uuid string
internalId = null;
}
if (internalId != null)
return internalId;
else { /*translate uuid logic here */}
Regards.
________________________________________
From: Nitin Mehta [nitin.me...@citrix.com]
Sent: Friday, December 28, 2012 9:08 AM
To: cloudstack-users@incubator.apache.org
Cc: cloudstack-...@incubator.apache.org
Subject: Re: [VOTE] Enforcing UUID string in API query
Hi Rohit,
I didn't understand the rationale behind this. Can you please explain ? thanks
On 28-Dec-2012, at 5:12 AM, Rohit Yadav wrote:
> Alright, spoke with tsp on irc on testing methods etc. I fixed [1] the
> apiserver to make it backward compatible;
>
> - For all pre 3.x apis, both uuid, internal id can be used, all pre 3.x apis
> don't have since field in their annotation.
> - For post 3.x apis, uuid param checking is enforced.
>
Can you please explain me the relation with 3.x api's ? I guess what Will said
that all the objects (resources) created pre 3.x will have just ID populated
and not the UUID. Also I saw the code and there is regex check for UUID. I am
afraid that will impact the performance.
> The response (xml or json) always had uuid (and not internal id) since 3.x
> which is fine with everyone and I fail to understand the case.
>
> [1]
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=623e7389ef0b2923b7859629cd70406e2e471525
>
> Regards.
>
> On 27-Dec-2012, at 2:04 PM, Will Chan <will.c...@citrix.com> wrote:
>
>> 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.
>>>>
>>
>
