[keycloak-dev] triple abstraction?

[Bill Burke]

On 7/8/2014 12:01 PM, Stian Thorgersen wrote:
> I thought we where at an agreement with splitting the model. If that's not the case, and to be able to actually do a release sometime soon, I propose we just revert back to how it was before.
>

I did not know you were going to write a completely new persistence 
abstraction underneath our existing persistence abstraction.  I thought 
the existing Model interfaces were going to be retained/refactored and 
you were just going to split out how UserModel, Realm, and UserSessions 
were looked up.

> For argument sake the benefits for this split include:
>
> * Users are what we need to federate, this split makes that a lot simpler IMO
> * Users are what people may want to store in their own schema, again this makes it a lot simpler IMO
> * Can store different things in different store types. For example realms in a json file, users in a relational database and sessions in a in-mem data-grid
> * Realms store can be changed if we need to. Relative quick and easy to export/import to update.
> * Users store shouldn't be changed frequently. Updating a database with 20 million entries is non-trivial

All you did to improve the 20 million use case was remove secondary key 
constraints from UserEntity and UserRoleMappingEntity, which could have 
been done in the existing model.

> * Model was getting pretty big and complex, with loads of tables. Splitting makes it simpler IMO
>

Bah! our data model is not complex!

Summary of my perspective

* Model API was written so that the implementation details of storage 
wouldn't be exposed to the service layer.  So, if we retired the Model 
API in favor of using the Hybrid API, the service layer would be dealing 
with user ids, role ids, realm ids, client ids, instead of UserModel, 
RoleModel, RealmModel, and ClientModel.
* The Adapter classes existed to bridge between the Model API and the 
persistence API.  I think you lost that notion in the Hybrid model as it 
is completely String ID based.
* The line between AuthentcationProvider and UserProvider is now blurred 
and confusing as they both provide a mechanism to create and look up 
users.  I'm not even sure you could have a LDAP store that is both a 
UserProvider and AuthenticationProvider.


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