flyrain commented on code in PR #808:
URL: https://github.com/apache/polaris/pull/808#discussion_r1956768340
##########
spec/rest-catalog-open-api.yaml:
##########
@@ -1595,6 +1595,261 @@ paths:
$ref: '#/components/responses/ServiceUnavailableResponse'
5XX:
$ref: '#/components/responses/ServerErrorResponse'
+
+ /v1/{prefix}/namespaces/{namespace}/policies:
Review Comment:
Let me break down the difference between policy ownership and policy
assignment a bit.
Policy Ownership:
Think of this as where the policy "lives" and how it's managed. For example,
a policy might be identified as `c1.ns1.policy1`, meaning it's part of a
specific namespace. When you delete a namespace, you need to clean up
everything under it—including the policies. This helps keep things organized.
Also, in many companies, there's a dedicated team that's responsible for
defining policies. They don't own any tables themselves, but they do manage the
policies under a namespace (or something similar like a schema). Grouping
policies under a namespace works well in this setup.
Policy Assignment:
Just because a policy exists in a namespace doesn't mean it automatically
applies there. You have to actively assign the policy to a specific resource,
like a catalog, namespace, or table. Think of it like having a rule book that's
stored in a specific area, but you only use a rule when you decide to apply it
to a particular situation. The following diagram shows how this assignment
works in practice.
Another key reason for placing policies under a namespace is that it
reinforces the purpose of the namespace: grouping real objects. If policies
were placed directly under a catalog, they would become mixed with the grouping
layer, potentially increasing the complexity and maintenance burden of the
system. This approach aligns with practices used by other systems such as
Snowflake, Dremio and Unity Catalog.
--
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]
