[
https://issues.apache.org/jira/browse/HIVE-29035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105227#comment-18105227
]
Shohei Okumiya commented on HIVE-29035:
---------------------------------------
[~henrib]
How do you think the following development order?
# In HIVE-29035, we will develop only the L2 cache first. At this point, I
presume the L2 cache does not change our authz semantics
# In HIVE-29817, we will develop the secure L1 cache with proper authorization
I think we should not merge insecure features as much as possible. It might
mislead end users and security researchers, or it might even block our release.
Also, I currently assume we can inject additional authorization only when the
L1 cache is hit. After glancing at #6702, I think the permission is likely
evaluated twice. I'd like to discuss this further, so I'd like to review L2
first.
> Fixing cache handling for REST catalog
> --------------------------------------
>
> Key: HIVE-29035
> URL: https://issues.apache.org/jira/browse/HIVE-29035
> Project: Hive
> Issue Type: Improvement
> Components: Iceberg integration, Standalone Metastore
> Reporter: Shohei Okumiya
> Assignee: Henri Biestro
> Priority: Major
> Labels: pull-request-available
>
> We initially implemented the server-side caching with CachingCatalog, but
> disabled it in HIVE-29016.
> We have some unknowns about the caching architecture.
> * Where should we cache? Client? REST Catalog? Thrift?
> * What should we cache? HMS's records? Manifest?
> * What strategy is needed to ensure the cache coherency?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
