[keycloak-dev] Use UUID for IDs

[Bill Burke]

IIRC, String ids was an artifact from when we used Picketlink as the 
sole backend store.  Why wouldn't we just use a Long and use whatever 
facility the persistence layer has for generating unique ids?  (i.e. a 
sequence)?

+1 that current IdGenerator sucks.  My bad.  I should know better (and 
have done better in the past, and have even used UUID in the past). 
Don't know what I was thinking...

On 2/12/2014 6:30 AM, Stian Thorgersen wrote:
> I'm confused - so let's clarify:
>
> Let's use IdGenerator to create IDs, but replace the implementation with:
>
> public class IdGenerator {
>    public static String generateId() {
>      return java.lang.UUID.randomUUID().toString();
>    }
> }
>
> * IdGenerator as it stands doesn't work. For example it won't work in a cluster. It also could quite likely generated duplicates if a server is restarted after the time has been changed (admin restarts server, realizes time is 60 min wrong, fixes that and starts Keycloak).
>
> We'll then use this to generate IDs when creating new realms, apps, users, roles, etc. (for all model implementations). In the model api and in the db these will be 128-bits strings.
>
> I don't see the need for TokenIdGenerator and we should use IdGenerator for that as well.
>
> If there is a demand for it in the future, we could investigate a better solution. For example we could get away with a smaller id (64-bits?), we could generate sequential UUIDs to improve db performance, etc. In the short/medium term though, we have other higher priorities.
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Bruno Oliveira" <bruno at abstractj.org>, "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 11 February, 2014 11:38:56 PM
>> Subject: Re: [keycloak-dev] Use UUID for IDs
>>
>> I wonder if it's not better to just use Long instead of String? In
>> GateIn portal we use old Picketlink IDM backed by Hibernate and we have
>> autogenerated Ids of type Long, which are "externally" seen as Strings,
>> so it's not a problem to keep getId() method in API returning String.
>>
>> See the class here (and getter/setters for Strings):
>> https://github.com/picketlink/picketlink-idm/blob/1.4/picketlink-idm-hibernate/src/main/java/org/picketlink/idm/impl/model/hibernate/HibernateIdentityObject.java#L55
>> and Hibernate mapping:
>> https://github.com/picketlink/picketlink-idm/blob/1.4/picketlink-idm-hibernate/src/main/resources/mappings/HibernateIdentityObject.hbm.xml#L8
>>
>> The most important thing is, that this is tested and works with all
>> major databases (H2, MySQL, PostgreSQL, IBM DB2, Oracle, Sybase, MSSQL).
>> Another thing is that long might have better performance than String.
>>
>> I am not sure about the usecase with import/export stuff from/into
>> completely different DB (like have data in H2, then export them and then
>> import same data into MySQL). This may not work as different DBs may
>> have different rules for allowing ID (some may have unique ID just for
>> single table, some may enforce to have unique ID globally). However I am
>> also not sure if String Id like "1-898928392" is allowed in all RDBMS...
>>
>> Marek
>>
>>
>> On 11.2.2014 15:13, Bruno Oliveira wrote:
>>> +1 I guess TokenIdGenerator does the job well
>>>
>>
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com