singhpk234 commented on code in PR #3724:
URL: https://github.com/apache/iceberg-python/pull/3724#discussion_r3808188020
##########
mkdocs/docs/configuration.md:
##########
@@ -386,6 +386,10 @@ catalog:
| snapshot-loading-mode | refs | The snapshots to
return in the body of the metadata. Setting the value to `all` would return the
full set of snapshots currently valid for the table. Setting the value to
`refs` would load all snapshots referenced by branches or tags. |
| `header.X-Iceberg-Access-Delegation` | `vended-credentials` | Signal to the
server that the client supports delegated access via a comma-separated list of
access mechanisms. The server may choose to supply access via any or none of
the requested mechanisms. When using `vended-credentials`, the server provides
temporary credentials to the client. When using `remote-signing`, the server
signs requests on behalf of the client. (default: `vended-credentials`) |
| view-endpoints-supported | false | For backwards
compatibility with older REST servers. Set to `true` if the server supports
view endpoints but doesn't send the `endpoints` field in the ConfigResponse. |
+| scan-planning-mode | client | When set to `server`, and the catalog
advertises the plan-table-scan endpoint, `table.scan()` uses REST server-side
scan planning. May be set by the client, returned by the catalog via `GET
/v1/config` defaults/overrides, or returned per table in the `config` of the
`loadTable` response. The `loadTable` value takes precedence over the
catalog-level value, which lets a server request server-side planning only for
specific tables. Async plans (`status=submitted`) are polled via `GET
.../plan/{plan-id}` until completion. |
Review Comment:
```suggestion
| scan-planning-mode | client | When set to `server`, and the catalog
advertises the plan-table-scan endpoint, `table.scan()` uses REST server-side
scan planning. May be set by the client, returned by the catalog via `GET
/v1/config` defaults/overrides, or returned per table in the `config` of the
`loadTable` response. The `loadTable` value takes precedence over the
catalog-level value, which lets a server request server-side planning only for
specific tables. Async plans (`status=submitted`) are polled via `GET
.../plan/{plan-id}` until terminal state (completed / failed / cancelled). |
```
##########
mkdocs/docs/configuration.md:
##########
@@ -386,6 +386,10 @@ catalog:
| snapshot-loading-mode | refs | The snapshots to
return in the body of the metadata. Setting the value to `all` would return the
full set of snapshots currently valid for the table. Setting the value to
`refs` would load all snapshots referenced by branches or tags. |
| `header.X-Iceberg-Access-Delegation` | `vended-credentials` | Signal to the
server that the client supports delegated access via a comma-separated list of
access mechanisms. The server may choose to supply access via any or none of
the requested mechanisms. When using `vended-credentials`, the server provides
temporary credentials to the client. When using `remote-signing`, the server
signs requests on behalf of the client. (default: `vended-credentials`) |
| view-endpoints-supported | false | For backwards
compatibility with older REST servers. Set to `true` if the server supports
view endpoints but doesn't send the `endpoints` field in the ConfigResponse. |
+| scan-planning-mode | client | When set to `server`, and the catalog
advertises the plan-table-scan endpoint, `table.scan()` uses REST server-side
scan planning. May be set by the client, returned by the catalog via `GET
/v1/config` defaults/overrides, or returned per table in the `config` of the
`loadTable` response. The `loadTable` value takes precedence over the
catalog-level value, which lets a server request server-side planning only for
specific tables. Async plans (`status=submitted`) are polled via `GET
.../plan/{plan-id}` until completion. |
+| rest-scan-planning.poll-timeout-ms | 300000 | Maximum time to wait for an
async scan plan to complete before failing (default: 5 minutes). |
+
+When server-side planning returns `storage-credentials` on a completed plan,
PyIceberg applies them to the scan-scoped FileIO (layered on top of the
existing table/load-time IO properties) so planned data and delete files can be
read.
Review Comment:
```suggestion
When server-side planning returns `storage-credentials` on a completed plan,
PyIceberg applies them to the scan-scoped FileIO (layered on top of the
existing table/load-time IO properties) so planned data and delete files can be
read using the creds vended by the server.
```
--
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]
