[keycloak-dev] Use UUID for IDs

[Bill Burke]

Stian, whatever you want.  I honestly haven't written a RDBMS 
application in 10+ years.  Only best practices I know were absorbed 
through osmosis by being so close to the JPA/EJB3 efforts in mid-2000s 
or by listening/responding to users on those forums.

On 2/12/2014 10:05 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Marek Posolda" <mposolda at redhat.com>, "Bruno Oliveira" <bruno at abstractj.org>, keycloak-dev at 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
>>

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