laserninja commented on code in PR #11634:
URL: https://github.com/apache/gravitino/pull/11634#discussion_r3792391333
##########
iceberg/iceberg-rest-server/src/main/java/org/apache/gravitino/iceberg/service/CatalogWrapperForREST.java:
##########
@@ -181,6 +181,20 @@ public LoadCredentialsResponse getTableCredentials(
}
}
+ /**
+ * Whether this catalog wrapper supports server-side scan planning.
+ *
+ * <p>Gravitino implements scan planning locally on top of loaded table
metadata. For non-REST
+ * backends (Hive, JDBC, Memory, Custom) this always works. For REST
backends the upstream catalog
+ * owns scan planning; advertising the endpoint here could be misleading
when the upstream does
+ * not support it, so we do not advertise it.
+ *
+ * @return {@code true} if the scan-plan endpoint should be advertised
+ */
+ public boolean supportsScanPlanOperations() {
Review Comment:
Done, pushed in `92edf5b`.
`CatalogWrapperForREST.supportsScanPlanOperations()` now returns `true`
(Gravitino plans locally for every backend it handles directly), and
`FederatedCatalogWrapper` overrides it to report whether the remote advertises
`V1_SUBMIT_TABLE_SCAN_PLAN` in its own `/v1/config`. Cached for the wrapper's
lifetime so the remote is queried at most once, not per local `/v1/config` call.
Two behaviours worth calling out:
- A remote that omits `endpoints` is treated as not supporting scan
planning. That matches the Iceberg client, which falls back to a default
endpoint set predating scan planning when the field is absent.
- A failed lookup is not cached and does not advertise the endpoint, so it
can resolve once the remote recovers.
One thing outside the strict scope, so say the word if you'd rather I split
it: `getRESTTableCredentials` and `getRESTTablePlanScan` each carried their own
copy of the auth manager / client / session lifecycle, and the config fetch
would have been a third. I pulled it into `callRemoteCatalog` instead. It's a
separate commit-sized change if you prefer it out of this PR.
--
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]
