rdblue commented on a change in pull request #3955:
URL: https://github.com/apache/iceberg/pull/3955#discussion_r791246200
##########
File path: rest_docs/rest-catalog-open-api.yaml
##########
@@ -367,6 +367,90 @@ paths:
- $ref: '#/components/parameters/namespace'
- $ref: '#/components/parameters/table'
+ get:
+ tags:
+ - Catalog API
+ summary: Load a table from the catalog
+ operationId: loadTable
+ description:
+ Load a table from the catalog.
+
+ The response contains both configuration and table metadata. The
configuration, if non-empty is used
+ as additional configuration for the table that overrides catalog
configuration. For example, this
+ configuration may change the FileIO implemented used for the table.
+
+ The response also contains the table's full metadata.
+ responses:
+ 200:
+ $ref: '#/components/responses/LoadTableResponse'
+ 400:
+ $ref: '#/components/responses/BadRequestErrorResponse'
+ 401:
+ $ref: '#/components/responses/UnauthorizedResponse'
+ 404:
+ description:
+ Not Found - NoSuchTableException, table to load does not exist
+ content:
+ application/json:
+ schema:
+ $ref: '#/components/responses/IcebergErrorResponse'
+ examples:
+ TableToRenameDoesNotExist:
+ $ref: '#/components/examples/NoSuchTableError'
+ 5XX:
+ $ref: '#/components/responses/ServerErrorResponse'
+
+ post:
+ tags:
+ - Catalog API
+ summary: Commit updates to a table
+ operationId: updateTable
+ description:
+ Commit updates to a table.
+
+ Commits have two parts, requirements and updates. Requirements are
assertions that will be validated
+ before attempting to make and commit changes. For example,
assert-ref-snapshot-id will check that a
+ named ref's snapshot ID has a certain value.
+
+ Updates are changes to make to table metadata. For example, after
asserting that the current main ref
+ is at the expected snapshot, a commit may add a new child snapshot and
set the ref to the new
+ snapshot id.
+ requestBody:
+ content:
+ application/json:
+ schema:
+ $ref: '#/components/schemas/CommitTableRequest'
+ responses:
+ 200:
+ description: OK
+ content:
+ application/json:
+ schema:
+ $ref: '#/components/responses/CommitTableResponse'
+ 400:
+ $ref: '#/components/responses/BadRequestErrorResponse'
+ 401:
+ $ref: '#/components/responses/UnauthorizedResponse'
+ 404:
+ description:
+ Not Found - NoSuchTableException, table to load does not exist
+ content:
+ application/json:
+ schema:
+ $ref: '#/components/responses/IcebergErrorResponse'
+ examples:
+ TableToRenameDoesNotExist:
+ $ref: '#/components/examples/NoSuchTableError'
+ 409:
+ description:
+ Conflict - CommitFailedException, one or more requirements failed.
The client may retry.
Review comment:
Good question. I think that we do have the possibility of unknown commit
state for the same reasons we have it in the other catalog clients. If this is
sending the update off to a DB and gets disconnected, then there's a
possibility that the commit succeeded but the service doesn't know about it. We
can't guarantee that the service endpoint always knows the final commit state.
However, I don't think that this should actually send `CommitStateUnknown`.
Instead, it should send a 5xx error and trigger commit state recovery on the
client side. That way, we don't have retries within retries. The client would
get the complete server-side error, then query the table to see whether the
commit succeeded. If it did, then it would return success and if not would
throw its own `CommitStateUnknownException`.
--
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]
