[keycloak-dev] Use UUID for IDs

[Stian Thorgersen]

We've come full circle ;)

My reasoning for not to use db generated ids are:

* ID format would be different depending on the store (H2, MySQL, PostgreSQL, Oracle, Mongo, etc.) / for example apps will want to refer to users by id, and they need to know how to store it
* What happens to a "sequences" (or whatever mechanism the db chooses to use) if you export to json, then import again. Especially if you change the underlying db (e.g. from H2 to PostgreSQL)

Further (this is a stupid reason) if we want to support huge deployments shards will be involved, in which case it'd be simpler to use UUIDs.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: "Bruno Oliveira" <bruno at abstractj.org>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 12 February, 2014 1:54:20 PM
> Subject: Re: [keycloak-dev] Use UUID for IDs
> 
> 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
>