Commit updates to a table

post

{scheme}://{host}/{basePath}/v1/{prefix}/namespaces/{namespace}/tables/{table}

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. Server implementations are required to fail with a 400 status code if any unknown updates or requirements are received.

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.

Create table transactions that are started by createTable with stage-create set to true are committed using this route. Transactions should include all changes to the table, including table initialization, like AddSchemaUpdate and SetCurrentSchemaUpdate. The assert-create requirement is used to ensure that the table was not created concurrently.

Recent Requests

Time	Status	User Agent
Retrieving recent requests…

Loading…

Path Params

prefix

string

required

An optional prefix in the path

namespace

string

required

A namespace identifier as a single string. Multipart namespace parts should be separated by the unit separator (0x1F) byte.

table

string

required

A table name

Body Params

identifier

object

Table identifier to update; must be present for CommitTransactionRequest

requirements

array of objects

required

requirements*

updates

array of objects

required

updates*

Responses

Language

Credentials

URL

Loading…

Response

Click Try It! to start a request and see the response here! Or choose an example:

application/json

200Response used when a table is successfully updated. The table metadata JSON is returned in the metadata field. The corresponding file location of table metadata must be returned in the metadata-location field. Clients can check whether metadata has changed by comparing metadata locations.

400Indicates a bad request error. It could be caused by an unexpected request body format or other forms of request validation failure, such as invalid json. Usually serves application/json content, although in some cases simple text/plain content might be returned by the server's middleware.

401Unauthorized. The REST Catalog SHOULD respond with the 401 UnauthorizedResponse when the access token provided is expired, revoked, malformed, or invalid for other reasons. The client MAY request a new access token and retry the request.

403Forbidden. Authenticated user does not have the necessary permissions.

404Not Found - NoSuchTableException, table to load does not exist

409Conflict - CommitFailedException, one or more requirements failed. The client may retry.

419This is an optional status response type that the REST Catalog can issue when the token has expired. The client MAY request a new access token and retry the request. 401 UnauthorizedResponse SHOULD be preferred over this response type on token expiry.

500An unknown server-side problem occurred; the commit state is unknown.

502A gateway or proxy received an invalid response from the upstream server; the commit state is unknown.

503The service is not ready to handle the request, request could have been partially processed. The service may additionally send a Retry-After header to indicate when to retry, a non idempotent request should only be retried by the client when the Retry-After header is present.

504A server-side gateway timeout occurred; the commit state is unknown.

5XXA server-side problem that might not be addressable on the client.