rahil-c commented on code in PR #9695:
URL: https://github.com/apache/iceberg/pull/9695#discussion_r1742462669
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3647,6 +4080,105 @@ components:
type: integer
description: "List of equality field IDs"
+ PlanTableScanRequest:
+ type: object
+ properties:
+ snapshot-id:
+ description:
+ Identifier for the snapshot to scan in a point-in-time scan
+ type: integer
+ format: int64
+ select:
+ description: List of selected schema fields
+ type: array
+ items:
+ $ref: '#/components/schemas/FieldName'
+ filter:
+ description:
+ Expression used to filter the table data
+ $ref: '#/components/schemas/Expression'
+ case-sensitive:
+ description: Enables case sensitive field matching for filter and
select
+ type: boolean
+ default: true
+ use-snapshot-schema:
+ description:
+ Whether to use the schema at the time the snapshot was written.
+
+ When time travelling, the snapshot schema should be used (true).
+ When scanning a branch, the table schema should be used (false).
+ type: boolean
+ default: false
+ start-snapshot-id:
+ description: Starting snapshot ID for an incremental scan (exclusive)
+ type: integer
+ format: int64
+ end-snapshot-id:
+ description:
+ Ending snapshot ID for an incremental scan (inclusive).
+
+ Required when start-snapshot-id is specified.
+ type: integer
+ format: int64
+ stats-fields:
+ description:
+ List of fields for which the service should send column stats.
+ type: array
+ items:
+ $ref: '#/components/schemas/FieldName'
+
+ FieldName:
+ description:
+ A full field name (including parent field names), such as those passed
+ in APIs like Java `Schema#findField(String name)`.
+
+ The nested field name follows these rules
+ - Nested struct fields are named by concatenating field names at each
+ struct level using dot (`.`) delimiter, e.g.
+ employer.contact_info.address.zip_code
+ - Nested fields in a map key are named using the keyword `key`, e.g.
+ employee_address_map.key.first_name
+ - Nested fields in a map value are named using the keyword `value`,
+ e.g. employee_address_map.value.zip_code
+ - Nested fields in a list are named using the keyword `element`, e.g.
+ employees.element.first_name
+ type: string
+
+ FetchScanTasksRequest:
+ type: object
+ required:
+ - plan-task
+ properties:
+ plan-task:
+ $ref: '#/components/schemas/PlanTask'
+
+ PlanTask:
+ description:
+ An opaque JSON object provided by the REST server that represents a
Review Comment:
@danielcweeks @jackye1995 @rdblue I am also ok with representing `PlanTask`
as an `opaque string` as it is the most simple for both client and service to
send/receive. I think it also offers more flexibility as for what the planTask
can be. My only question then is we go with `string` are we being explicit in
the description that this is a `opaque JSON string` or do we leave it up for
service to provide anything for this?
--
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: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
