dennishuo commented on PR #321: URL: https://github.com/apache/polaris/pull/321#issuecomment-2378114368
> It would be nice to have a general `checkPrivileges` API so that a user can validate any privilege they require. it doesn't cover everything that's needed here, but maybe it's possible that we could model a privilege check to contain the information needed to actually validate most of the requirements. e.g., a `TableGrant` currently contains the privilege and the namespace and table name. For default table locations, that's all you'd need to validate create/read/write privileges. For custom table locations, we'd need a different entity to validate the location. Yeah good point - I definitely also considered something along the lines of a "dry-run" parameter for this instead that could be generalized to other API requests. In this case when I started implementing it that way it became clear that there are enough deviations for the use case that it would be a bit misleading and messy to treat it as a dry run. In particular, this use case seems to pop up more prominently due to the inherently "cooperative" nature of the intended federation use case of the Notifications API, where a remote catalog wants to pre-validate before creating any metadata files on their side. This also means the control flow isn't quite the same as e.g. injecting a no-op metastore for writes while exercising all reads the same as "real" calls. I agree it'll be nice to have some generalized prevalidation longer-term though. `checkPrivilege` with the ability to expand the validation to things like location-validation and config-validation sounds like a good alternative vs `dry-run` to capture the fact that the validation set might need to be a different workflow than what a simple `dry-run` might imply. Another thing that makes me want to lean towards a more targeted initial scope here is that the Notification API is more actively experimental while we better align in the broader community on the concept of external tables (https://lists.apache.org/thread/zcv6qm9ysknrhfpg093qgnrkrolptcht) so as long as the intended use case is something we see long-term (the use case of prevalidation/checkPrivilege/etc) then it makes sense to iterate on a narrower implementation that could change easily and then we can apply learnings from the use case towards the generalization of the implementation. -- 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]
