Create a new table version
Create a new version entry for table id.
This operation supports put_if_not_exists semantics. The operation will fail with 409 Conflict if the version already exists.
Request body
Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation.
On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller.
REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the header. prefix:
- On a request, any entry whose key starts with header. is sent as an HTTP request header with the prefix stripped. For example, the entry {"header.Authorization": "Bearer abc"} is sent as the request header Authorization: Bearer abc.
- On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with header.. For example, the response header x-request-id: abc123 is returned as the entry {"header.x-request-id": "abc123"}.
The table identifier
Version number to create
Branch to target. When not specified, the main branch is used.
Path to the manifest file for this version
Size of the manifest file in bytes
Optional ETag for the manifest file
Optional metadata for the version
The naming scheme used for manifest files in the _versions/ directory.
Known values:
- V1: _versions/{version}.manifest - Simple version-based naming
- V2: _versions/{inverted_version}.manifest - Zero-padded, reversed version number (uses u64::MAX - version) for O(1) lookup of latest version on object stores
V2 is preferred for new tables as it enables efficient latest-version discovery without needing to list all versions.
Example request
{
"naming_scheme": "V2"
}Response
Result of creating a table version
Arbitrary context as key-value pairs. How to use the context is custom to the specific implementation.
On a request, it carries caller-provided context to the implementation. On a response, it carries implementation-provided context back to the caller.
REST NAMESPACE ONLY Context entries are mapped to and from HTTP headers using the header. prefix:
- On a request, any entry whose key starts with header. is sent as an HTTP request header with the prefix stripped. For example, the entry {"header.Authorization": "Bearer abc"} is sent as the request header Authorization: Bearer abc.
- On a response, every HTTP response header is returned as an entry whose key is the header name prefixed with header.. For example, the response header x-request-id: abc123 is returned as the entry {"header.x-request-id": "abc123"}.
Optional transaction identifier