8:03 a.m.
On 7/17/2014 6:31 AM, Marek Posolda wrote:
On 17.7.2014 01:42, Bill Burke wrote:
> I refactored some things for both performance and for bulk delete of
> users.
>
> * use long @Id for all non-exposed entities, i.e. UserRoleMappingEntity,
> etc. This is more efficient than strings
> * Ditched all @ElementCollections from UserEntity. Bulk delete does not
> cascade and there is no way to bulk delete @ElementCollections from
> JPAQL! This caused me to add UserAttributeEntity and
> UserRequiredActionEntity
> * Added @ManyToOne UserEntity relationship to AuthenticationLinkEntity
> so that it can be bulk deleted.
>
> Questions:
>
> I'm not sure about moving things like social links to UserAttributes.
> SocialLinkEntity, UserRoleMappingEntity, UserRequiredActionEntity are
> all in separate tables. Except for AuthenticationLinkEntity, which I
> hope to deal away with on the AuthenticationProvider refactor, I think
> UserEntity is fine the way it is.
I wonder that something like AuthenticationLinkEntity (even if named
differently) will be still needed? For users synced from LDAP, you may
want to keep the link to LDAP to particular user?
I don't think AuthenticatioLinkEntity should be part of the UserModel
API. The reason being is that this is metadata specific to the
"federation provider" and may be different per "federation provider".
>
> Are we *ABSOLUTELY* sure we want to remove secondary key constraints
> from UserRoleMappingEntity and UserEntity for role and realm
> respectively? These constraints caught a lot of problems for me that I
> wouldn't have found otherwise. I just don't think we'd ever store users
> and realms in different stores.
I am not sure about. Just want to point the usecase with migration
between versions. For example if Realm change between Keycloak 1.0 and
Keycloak 1.1, people may want to migrate their database (hence they
export realmModel to JSON, transform it to 1.1 and import it again). And
if user model won't change between versions, people won't need to
export/import and delete all users as it's quite overhead to do it if
they have like 20 million users in DB. Hence it might be useful if it's
possible to delete just realm model stuff, but still keep all users in
DB. Will it be possible with these constraints?
Ah, really good point. Can't drop realm tables or export-reimport realm
data and keep users around.
Also doesn't similar problem exists for user sessions as well? I
mean
that with bulk deleting of users, it seems that UserSessions for
particular user are not deleted? Probably not a big issue as there is
periodic cleanup of sessions...
Good point, but I think Stian has it covered with
UserSessionProvider.onRealmRemoved().
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com