flyrain commented on code in PR #808:
URL: https://github.com/apache/polaris/pull/808#discussion_r1929078968
##########
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:
When it comes to deciding whether policies should live under catalogs or
namespaces, there’s no definitive answer—it’s more about implementation
preferences and what fits best for the system. That said, looking at examples
from systems like Snowflake and Dremio, they both place policies under
namespaces, and there are some clear benefits to doing so. It provides
consistency in entity organization. Tables and views are "real" objects, the
actual data entities, while catalogs and namespaces serve as layers to organize
them. By placing policies under namespaces, you maintain this hierarchy,
keeping things clean and logical.
We organically want polices owned by a catalog as you can see from the
design doc, due to the reason that we don’t allow applying policies
across-catalogs. But we removed that limit later, so that putting them under a
catalog isn’t compelling any more, as we still have to check if all policies
are used when we delete them as a batch. We can still put them under a catalog,
but it means there are two sets of endpoints for policy CRUD. With that, I
think it is fine to put polices under a namespace as the initial
implementation. We could add new endpoints if needed in the future.
--
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]
