ramackri opened a new pull request, #980:
URL: https://github.com/apache/ranger/pull/980

   ## What changes were proposed in this pull request?
   
   Optimized `RoleRefUpdater` and related role-ref DAOs so role create/update 
performs fewer database round-trips when a role references many users, groups, 
and sub-roles. The design mirrors 
[RANGER-3899](https://issues.apache.org/jira/browse/RANGER-3899) / PR 
[#962](https://github.com/apache/ranger/pull/962) (`PolicyRefUpdater`).
   
   ### Problem
   
   When creating or updating a role with a large number of principals, Ranger 
Admin was slow because:
   
   1. **N+1 lookups** — Users, groups, and sub-roles were resolved with 
repeated per-name database calls during ref-table maintenance.
   2. **Full ref-table rebuild on every update** — 
`createNewRoleMappingForRefTable()` always called `cleanupRefTables()`, 
deleting all rows from `x_role_ref_user`, `x_role_ref_group`, and 
`x_role_ref_role`, then re-inserting every principal even when nothing changed.
   3. **Monolithic associator** — A single `RolePrincipalAssociator` took three 
collection parameters and populated one of them inside `doAssociate()`, which 
was harder to read and inconsistent with the refactored policy path.
   
   ### Changes
   
   #### Performance (`RoleRefUpdater`)
   
   - Added `isRefTableCleanupRequired` to `createNewRoleMappingForRefTable()`.
   - **Create** (`RoleDBStore`, `RoleREST`): `isRefTableCleanupRequired = 
false` — no selective cleanup on empty ref tables.
   - **Update** (`RoleDBStore`, `RoleREST`, add/remove users/groups/roles, 
import update): `true` — `cleanupRefTablesForUpdate()` deletes only principals 
removed from the role; unchanged principals are not re-inserted.
   - Batch principal ID resolution via `getIdsByUserNames` / 
`getIdsByGroupNames` / `getIdsByRoleNames` and `batchInsert()` for new ref rows.
   - `cleanupRoleUsers` / `cleanupRoleGroups` / `cleanupRoleRoles` accept the 
DAO as a parameter (same pattern as `PolicyRefUpdater`).
   
   #### Associator refactor (aligned with PR #962 review)
   
   Replaced `RolePrincipalAssociator` with three focused inner classes:
   
   | Class | `getRoleRef()` | `createRoleRef(Long)` |
   |-------|----------------|------------------------|
   | `RoleUserAssociator` | `XXRoleRefUser` for batch insert | Direct `create` 
on transaction commit |
   | `RoleGroupAssociator` | `XXRoleRefGroup` | Direct `create` on transaction 
commit |
   | `RoleRoleAssociator` | `XXRoleRefRole` | Direct `create` on transaction 
commit |
   
   Call-site pattern (same as `PolicyRoleAssociator` / `PolicyGroupAssociator` 
/ `PolicyUserAssociator`):
   
   ```java
   Long userId = userNameIdMap.get(userName);
   RoleUserAssociator associator = new RoleUserAssociator(userName, userId, 
roleId);
   
   if (userId != null) {
       XXRoleRefUser userRef = associator.getRoleRef();
       if (userRef != null) {
           xxRoleRefUsers.add(userRef);
       }
   } else if (isCreateNonExistentUGRs) {
       
rangerTransactionSynchronizationAdapter.executeOnTransactionCommit(associator);
   } else {
       throw restErrorUtil.createRESTException(...);
   }
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to