ealeonraz commented on issue #12150: URL: https://github.com/apache/gravitino/issues/12150#issuecomment-5173586885
A few design questions before I start implementing, since the answers change the shape of the change: **1. API shape.** For the fresh-read mode on `get`/`batchGet`, do you prefer an explicit read-mode enum (`get(ident, type, clazz, ReadMode.FRESH)`), a boolean overload, or separate `getFresh`/`batchGetFresh` methods? I lean toward an enum because it is self-documenting at call sites and greppable when auditing which reads are fresh, but I will follow your preference. Either way the existing signatures keep their current cached behavior via a default method, so nothing changes for current callers. **2. Refill behavior.** In `RelationalEntityStore#get` the cached path does lookup then refill (`cache.put(entity)` after `backend.get`). The issue says a fresh read should bypass both "unless the refill is version-fenced". Should a fresh read skip the refill entirely (simplest, and cannot resurrect a concurrently invalidated key), or do a version-fenced refill to keep the cache warm? Skipping is safer; fencing needs a version comparison on the cache entry. **3. Divergence handling.** If a fresh read returns a value that differs from what is cached, should it invalidate the stale entry as a side effect, or leave the cache untouched and let the normal invalidation path handle it? **4. Call-site list.** Is the list in the description exhaustive, or should my audit propose additions if I find other reads used as write or external-action preconditions? I plan to produce a table of every candidate site with a cached-or-fresh decision and a one-line justification, so the boundary is reviewable. **5. Sequencing.** You mentioned on #12020 that the Redis work should wait for the dependency issues. Does the same apply here, or is #12150 fine to land independently of #12149 and #12151? I would like to avoid conflicting with #12006 while it is still open. Happy to start with the audit while these are settled, since that part is independent of the API decision. -- 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]
