We already have a UUID column for few tables such as AM_API and
AM_APPLICATION which is used to uniquely identify a record. The reason why
we have a UUID column is because it is the unique identifier that we expose
to the end user. Having a UUID for this purpose means that end users cannot
guess th
Hi,
I was under the impression that the UUID was used as a result of having
registry and UUID was used to map the registry resource. Pls correct me if
I'm wrong.
When the registry is no longer present, I don't see a real use case of
going for a hybrid approach. Either we could use UUID as a PK or
We expose the unique UUID of a given artifact to the end user via REST
APIs. You can see how this is used in the REST API docs[1]. We cant use the
auto increment ID for this purpose for the reasons I mentioned earlier.
[1] https://docs.wso2.com/display/AM200/apidocs/publisher/index.html
On 18 Nov
Hi Uvindra,
After going through the links you've given and some other articles on
the web, I can see there are basically 2 main concerns about using UUIDs.
That's storage space and indexing effort. But since we anyway need UUIDs
even if we go for Hybrid approach we can ignore the space factor. The
Hi Uvindra,
The reason you mentioned is:
"Having a UUID for this purpose means that end users cannot guess the
possible unique identity of other entities, which is possible if we exposed
an integer based identifier."
What is the purpose of having a non guessable Id here? Anywhere the user
who has
Hi Lahiru,
One of the reasons to expose UUIDs instead of auto increment IDs in REST
resources is that if we expose auto increment ID, we unwillingly expose
certain internal information like how many resources we have in our system
and the pattern how we store these resources. That information can
Hi All
Another most obvious advantage of using UUIDs would that it will simplify
import/export of APIs. I am +1 for using UUIDs as primary keys.
Cheers
Jo
On Sat, Nov 19, 2016 at 12:42 PM, Bhathiya Jayasekara
wrote:
> Hi Lahiru,
>
> One of the reasons to expose UUIDs instead of auto increment
On Sat, Nov 19, 2016 at 3:38 PM, Joseph Fonseka wrote:
> Hi All
>
> Another most obvious advantage of using UUIDs would that it will simplify
> import/export of APIs. I am +1 for using UUIDs as primary keys.
>
In a more correct term UUIDs will simplify managing APIs cross
environments.
>
> Che
Hi Bathiya/Jo,
Thanks for the valuable information.
+1 for UUID as the PK
On Sat, Nov 19, 2016 at 3:41 PM, Joseph Fonseka wrote:
>
>
> On Sat, Nov 19, 2016 at 3:38 PM, Joseph Fonseka wrote:
>
>> Hi All
>>
>> Another most obvious advantage of using UUIDs would that it will simplify
>> import/ex
Just thought of pointing out that there is an option of optimizing UUIDs
stored in the DB to make them easier to sequence and reduce storage
size[1]. Though I doubt we will have such high volumes of data in a given
DB instance with the new C5 architecture so don't think we need to go down
this rout
Hi Uvindra,
One aspect to keep in mind is that if you have a lot of foreign key
references referring this table, all those tables will have a UUID if you
choose UUID as the primary key. This might affect the storage space and
indexing of those tables as well.
Thanks,
Akalanaka.
On Sun, Nov 20, 2
Yes Akalanka, that is one disadvantage that has been highlighted. But going
by the fact that the volume of data in a given DB instance reduces
drastically in C5 this may not be an issue. But only a perf test with real
data will reveal this for sure
On 21 November 2016 at 12:27, Akalanka Pagoda Ara
12 matches
Mail list logo
