Thanks for bringing this up, Jonas!
The changes make sense to me!
Yufei
On Sat, Mar 29, 2025 at 5:44 PM Honah J. <hon...@apache.org> wrote:
> Hi folks,
>
> I'd like to propose a change to our existing GetApplicablePolicies API
> endpoint (GET /v1/{prefix}/applicable-policies) and gather your feedback.
>
> Currently, this endpoint retrieves policies applicable to a given target
> (e.g., table or view), including those inherited from parent entities. For
> example, the UI may utilize this endpoint to identify and display policies
> like data compaction or metadata retention for a specific table.
>
> The existing API response includes the following fields for each policy:
>
> - name
> - type
> - inheritable
> - description
> - content
> - version
>
> However, these fields are insufficient for scenarios where users need to
> override a policy. Consider the following scenario:
>
> Suppose a data-compaction policy (P1) is assigned to namespace NS1, causing
> all tables within NS1 to inherit this policy. If a user wants to override
> the data-compaction setting specifically for a table (TB1) within NS1, they
> currently can only rely on the response from calling getApplicablePolicies
> on TB1. However, this response does not indicate:
>
> - The namespace where the applicable policy resides.
> - Whether the policy is directly attached to TB1 or inherited from a
> parent namespace.
>
> As a result, users cannot determine if modifying the current policy
> directly would inadvertently impact other tables. They also lack sufficient
> information to update the policy.
>
> To resolve this, I propose adding two additional fields to each applicable
> policy in the API response:
>
> -
>
> inherited: A boolean indicating if the policy is inherited from a parent
> entity.
> -
>
> namespaces: A hierarchical list showing the policy’s namespaces, ordered
> from the highest-level namespace down to the immediate parent.
>
> These fields enable users to decide whether to attach a new policy directly
> to TB1 or to update an existing policy without affecting settings on other
> tables
>
> Here is the draft PR for the proposed spec change:
> https://github.com/apache/polaris/pull/1277
>
> Looking forward to your feedback and suggestions!
>
> Best regards,
>
> Honah (Jonas)
>
