dennishuo commented on code in PR #2697:
URL: https://github.com/apache/polaris/pull/2697#discussion_r2408800685
##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/common/CatalogHandler.java:
##########
@@ -238,29 +241,52 @@ protected void
authorizeCreateTableLikeUnderNamespaceOperationOrThrow(
initializeCatalog();
}
+ /**
+ * Ensures resolution manifest is initialized for a table identifier. This
allows checking
+ * catalog-level feature flags or other resolved entities before
authorization. If already
+ * initialized, this is a no-op.
+ */
+ protected void ensureResolutionManifestForTable(TableIdentifier identifier) {
+ if (resolutionManifest == null) {
+ resolutionManifest =
+ resolutionManifestFactory.createResolutionManifest(
+ callContext, securityContext, catalogName);
+
+ // The underlying Catalog is also allowed to fetch "fresh" versions of
the target entity.
+ resolutionManifest.addPassthroughPath(
+ new ResolverPath(
+ PolarisCatalogHelpers.tableIdentifierToList(identifier),
+ PolarisEntityType.TABLE_LIKE,
+ true /* optional */),
+ identifier);
+ resolutionManifest.resolveAll();
+ }
+ }
Review Comment:
Forgot to respond here. Yeah the control flow extracting the
ResolutionManifest initialization looks good to me, and I agree it looks like
it won't do any extra persistence resolution calls.
I guess conceptually the generation of the ResolutionManifest doesn't need
to be strictly inlined in the authorize helper, even though it's intentionally
coupled a bit because the intent is that at least the filled-in
ResolutionManifest shouldn't "escape" to be used for any real actions before
authz has basically "approved" the manifest.
At some point we might want to attach some counters to our
ResolutionManifests and/or persistence impls so that in tests we can easily add
regression tests to ensure we don't accidentally add extraneous persistence
calls.
--
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]
