[keycloak-dev] need help on JPA schema changes

[Bill Burke]

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