Re: [keycloak-dev] Use UUID for IDs

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: "Marek Posolda" <mposolda(a)redhat.com&gt;, "Bruno Oliveira" <bruno(a)abstractj.org&gt;, keycloak-dev(a)lists.jboss.org > Sent: Wednesday, 12 February, 2014 2:56:50 PM > Subject: Re: [keycloak-dev] Use UUID for IDs > > > > On 2/12/2014 9:18 AM, Stian Thorgersen wrote: >> 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 > > Dbs will support long primary keys :) Sure, but if an IDs DB sequences (1, 2, 3, 4, 5, 6). That's what users will end up expecting. Then they change to Mongo and now suddenly the IDs are generated by Mongo (507f1f77bcf86cd799439011) they are different. > >> * 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) >> > > Export to json does not have to contain ids. Our import format doesn't > require ids. I'm not even sure it honors ids :) That depends why you export to json right? If you export to backup, to migrate to another db, or even to upgrade KC when the db schema has changed, you will expect the IDs to remain the same. > >> 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. >> > > That is beyond my experience so I don't have a counter argument to that. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com >