poojanilangekar commented on PR #2223: URL: https://github.com/apache/polaris/pull/2223#issuecomment-3160906462
Your concerns are valid and will be addressed as we implement the subsequent milestones for federation as outlined in [Apache Polaris Catalog Federation Proposal](https://docs.google.com/document/d/1Q6eEytxb0btpOPcL8RtkULskOlYUCo_3FLvFRnHkzBY/edit?tab=t.0#heading=h.dr4s0lqru4mo) and [Apache Polaris Federation - Non-REST Remotes, Credential Vending and Table-Level RBAC Outline](https://docs.google.com/document/d/19Vm0Uy-EyEYtgd2-bZpPICODOB3rYQJvHeqL1ODOOLc/edit?tab=t.0#heading=h.oqpqs0i41osq). As @dennishuo outlined in the document, the initial MVP creates synthetic entities. These synthetic entities are not "true" entities that are consistent with the source of truth catalog. Instead they allow Polaris to treat the components of a federated catalog as securables, much like entities in internal catalogs. Without this PR, users can only set catalog-level grants on federated catalogs -- making it unsuitable in cases they want to restrict access to tables/namespaces. The next step would be to JIT create entities, i.e., "Require actually fetching a successful response from the remote catalog before producing the synthetic passthrough facade entity" (as stated in the document). Lastly, when we implement all other parts of federation to support the (ultimate goal of catalog migration)[https://docs.google.com/document/d/1Q6eEytxb0btpOPcL8RtkULskOlYUCo_3FLvFRnHkzBY/edit?tab=t.0#bookmark=id.dm0mcu9wuv09], Polaris will support passthrough facade with caching and strongly-consistent cache-invalidation. This is PR is a building block needed to enable the future steps. -- 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: issues-unsubscr...@polaris.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
