----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 18 June, 2015 2:47:04 PM
Subject: Re: [keycloak-dev] Simplifying realm model
This would make things easier to store custom data too. It could be
extended to places where custom data could be prevalent. For example,
credential storage.
But here are the disadvantages:
* Do we have to worry about concurrency issues more though? All you
need is 2 concurrent admins modifying different settings in the realm
for one to overwrite the other. For example, one admin could be adding
a role, another could be configuring an identity provider. Sure, these
kind of concurrency issues exist now, but they are isolated because
realm model data is in different tables. Minimally, you would need some
kind of optimistic locking scheme that provided a non-cryptic error
message when there were collisions.
Yep, that's one of the bigger issues.
What I had in mind was to use optimistic locking and also make rest endpoints retry an
operation before returning an error to the admin.
For example adding an identity provider would still be a separate rest endpoint, so if it
fails to add it to the realm due to an optimistic locking exception it can simply retry
adding it.
* Admins would never be able to modify the database directly.
I don't think that's a problem - in theory they could as it would just be a json
doc so they could get it, change it, write it ;)
On 6/18/2015 5:19 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>, "keycloak
dev"
>> <keycloak-dev(a)lists.jboss.org>
>> Sent: Thursday, 18 June, 2015 10:59:42 AM
>> Subject: Re: [keycloak-dev] Simplifying realm model
>>
>> +1 to go this way for realm model. For users+userSessions I would likely
>> keep it in current form due to performance reasons, but for realm model
>> I am not seeing any issue to store it in blob as realm model doesn't
>> contain big amount of data. I am seeing just advantages and much simpler
>> migration and DB maintenance, which is currently pain.
>
> Yep, user model is much simpler in either case and isn't such a pain. We
> could probably clean it up a bit, but would certainly keep a proper schema
> for it with many tables and such.
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev