Re: [keycloak-dev] Use UUID for IDs

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(a)redhat.com&gt; > To: "Bruno Oliveira" <bruno(a)abstractj.org&gt;, "Bill Burke" <bburke(a)redhat.com&gt;, "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)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-hibe... > and Hibernate mapping: > https://github.com/picketlink/picketlink-idm/blob/1.4/picketlink-idm-hibe... > > 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 >> > >