[keycloak-dev] Use UUID for IDs

Bill Burke bburke at redhat.com
Wed Feb 12 08:54:20 EST 2014

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 

+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

More information about the keycloak-dev mailing list