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)
