yuqi1129 commented on code in PR #11702:
URL: https://github.com/apache/gravitino/pull/11702#discussion_r3427918961
##########
core/src/main/java/org/apache/gravitino/cache/SupportsRelationEntityCache.java:
##########
@@ -56,6 +56,24 @@ <E extends Entity & HasIdentifier> Optional<List<E>>
getIfPresent(
boolean invalidate(
NameIdentifier ident, Entity.EntityType type,
SupportsRelationOperations.Type relType);
+ /**
+ * Invalidates only the cached relation result for the given key, without
cascading through the
+ * reverse index.
+ *
+ * <p>Unlike {@link #invalidate(NameIdentifier, Entity.EntityType,
+ * SupportsRelationOperations.Type)}, this does not evict the reverse-index
mappings (which are
+ * shared across entities, e.g. all roles bound to one metadata object) or
other entities' caches.
+ * Use it when a relation result is known to be stale and the next read must
re-query the backend,
+ * but the shared reverse index must be preserved.
+ *
+ * @param ident the name identifier
+ * @param type the entity type
+ * @param relType the relation type
+ * @return true if the cache entry was removed
+ */
+ boolean invalidateRelationEntry(
Review Comment:
> It's only invoked from cache.put(entity) (i.e. store.put / store.get
cache-miss backfill). But grantPrivilegesToRole / overridePrivilegesInRole /
grantRolesToUser / grantRolesToGroup go through store.update, which calls
cache.invalidate(ident, type) — not cache.put — so invalidateOnKeyChange never
fires for them, and those are exactly the main trigger paths.
For the first one, I think you can call `invalidateOnKeyChange` in the
`store.update` as what you did in this PR.
If I missed something, please correct me.
> Dropping a single relation entry without a BFS cascade needs a dedicated
method (the existing invalidate(ident,type,relType) is also BFS), so
invalidateRelationEntry is the minimal necessary addition. Its Javadoc spells
out the difference from invalidate.
What's the problem of invaliding entity with BFS? Can you provide me with
more details?
--
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]
