Re: [keycloak-dev] triple abstraction?
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