[KULRICE-13135] Remove all membership mappings from GroupBo and RoleBo Created: 21/Aug/14  Updated: 16/Jan/15

Status: Open
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: None
Fix Version/s: 2.6
Security Level: Public (Public: Anyone can view)

Type: Improvement Priority: Major
Reporter: James Bennett Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: Old
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Similar issues:
KULRICE-7517Improve performance of RoleService by not loading membership information for the RoleBo for nearly every method call
KULRICE-10107Remove array and map initializing from component constructors
KULRICE-1996Remove lockCode from DocumentRouteHeaderValue
KULRICE-11468Add ability to remove mappings from superclass with JPA
KULRICE-2703Remove all the old Action List code/jsps from the codebase and struts mappings
KULRICE-4387Remove all deprecated code
KULRICE-5045Change to Role membership from the Role document causes the affected enroute document to re-queue, while role membership changes from person doc does not
KULRICE-4897Removal of toStringMapper, toStringBuilder, from BusinessObjectBase
KULRICE-3453Remove encryptedProperties from PojoFormBase and htmlControlAttribute
KULRICE-4575IM Person doc should only allow editing of direct group memberships
Rice Module:
KIM
KAI Review Status: Not Required
KTI Review Status: Not Required
Code Review Status: Not Required
Include in Release Notes?:
Yes
Story Points: 3

 Description   

The KIM group and role BOs both have memberships mapped with JPA annotations so the membership information is fetched whenever one of those BOs is retrieved using JPA. This is a significant performance problem when the group or role becomes large. At IU we have a few roles which have tens of thousands of users so whenever one of those role BOs is retrieved it causes a significant performance hit. It would be better if unbounded collections like these were not mapped up directly and instead went through a new API to explicitly fetch the role membership which is needed at any given point in the code. This will likely be a major refactor since the membership seems to be referenced in many different places in the code.

A while back IU contributed a performance improvement which includes the RoleBoLite class. I'd think that you could do away with that since it would be exactly the same as RoleBo once the membership mapping is removed.

Analysis: Review changes from RoleBoLite; Provide details on refactoring; Review for any impact for other projects


Generated at Thu Jul 09 06:58:18 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.