mchades commented on PR #10855:
URL: https://github.com/apache/gravitino/pull/10855#issuecomment-4328168792

   Thanks for the review! I traced through the cache call chains for FUNCTION 
and found that **no new production code is needed** — the existing mechanisms 
handle it generically:
   
   **1. OWNER_REL (e.g., after `registerFunction` sets the owner)**
   `RelationalEntityStore.insertRelation(OWNER_REL, funcIdent, FUNCTION, ...)` 
explicitly calls `cache.invalidate(funcIdent, FUNCTION, OWNER_REL)` on both 
sides before the DB write, so ownership cache is always fresh for any entity 
type including FUNCTION.
   
   **2. Securable-object deletion (role cache eviction)**
   `cache.invalidate(funcIdent, FUNCTION)` triggers a BFS prefix sweep that 
evicts all relation entries for `funcIdent`. The 
`ROLE_SECURABLE_OBJECT_REVERSE_RULE` registered in `ReverseIndexCache` further 
propagates the eviction to any `ROLE` entity that lists this FUNCTION as a 
securable object — so the role's cached securable-object list is also evicted 
and re-read from DB.
   
   Both paths work for **any** `EntityType` generically. The prerequisite — 
`MetadataObjectUtil.toEntityType(FUNCTION)` — is added by this PR, which is 
what unlocks FUNCTION in both paths.
   
   I've added two tests to `TestEntityStorageRelationCache` to make this 
explicit:
   - `testFunctionOwnerRelationCacheInvalidation`: OWNER_REL lifecycle for 
FUNCTION
   - `testRoleCacheEvictedOnFunctionDeletion`: BFS reverse-index eviction path 
when FUNCTION is deleted
   
   ---
   
   Regarding one remaining gap: when a *new role* with FUNCTION as a securable 
object is **inserted**, the cached 
`funcIdent:FUNCTION:METADATA_OBJECT_ROLE_REL` is not explicitly evicted 
(`invalidateOnKeyChange` currently only handles the `MODEL_VERSION→MODEL` 
parent-data dependency pattern). However, this same gap exists for 
TABLE/SCHEMA/FILESET and all other securable object types — it's a pre-existing 
issue unrelated to this PR. I've left it out of scope here to keep the PR 
focused.


-- 
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