Atomically create versions for multiple tables

Atomically create new version entries for multiple tables.

This operation is atomic: either all table versions are created successfully, or none are created. If any version creation fails (e.g., due to conflict), the entire batch operation fails.

Each entry in the request specifies the table identifier and version details. This supports put_if_not_exists semantics for each version entry.

Request body

contextContext

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"}.

Example request

{
  "entries": [
    {
      "naming_scheme": "V2"
    }
  ]
}

Response

Result of atomically creating table versions