singhpk234 commented on code in PR #14867:
URL: https://github.com/apache/iceberg/pull/14867#discussion_r2897087048
##########
core/src/main/java/org/apache/iceberg/rest/RESTSessionCatalog.java:
##########
@@ -595,9 +587,38 @@ private Supplier<BaseTable> createTableSupplier(
}
private RESTTable restTableForScanPlanning(
- TableOperations ops, TableIdentifier finalIdentifier, RESTClient
restClient) {
- // server supports remote planning endpoint and server / client wants to
do server side planning
- if (endpoints.contains(Endpoint.V1_SUBMIT_TABLE_SCAN_PLAN) &&
restScanPlanningEnabled) {
+ TableOperations ops,
+ TableIdentifier finalIdentifier,
+ RESTClient restClient,
+ Map<String, String> tableConf) {
+ // Get client-side and server-side scan planning modes
+ String clientModeConfig =
properties().get(RESTCatalogProperties.SCAN_PLANNING_MODE);
+ String serverModeConfig =
tableConf.get(RESTCatalogProperties.SCAN_PLANNING_MODE);
+
+ // Validate that client and server configs don't conflict
Review Comment:
> I do think that the right behavior in case of mismatch is to just use what
the server sent back and log the warning you mentioned
That sounds reasonable to me, my concern mostly was mostly from pov is that
there is way a client can force they wanna do client side only to the server,
but i agree there is nothing a client can do to stop server sending the
`server` as the mode even if keep feeling, its kind of in a mercy of the
server.
From Protocol pov also it seems like server has a final say so far for all
the configs sent and conviniently override the clients will / expectations.
All in Log a warning seems a reasonable middle ground for the client to be
aware that this is happening, i will go ahead and change the precondition to
log warning instead of fail, as i don't have a very strong opinion on failing
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
