v1

latestOpenAPI 3.1.1Apache 2.02026-07-2654130166.5 KB

MaterializedView

Data

Trigger an async materialized view refresh

Trigger an asynchronous refresh job for materialized view id. Returns a job ID for tracking.

post/v1/materialized_view/{id}/refresh

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

idstring[]

Table identifier path (namespace + table name)

src_versioninteger nullable

Optional source version to refresh from

max_rows_per_fragmentinteger nullable

Optional maximum rows per fragment

concurrencyinteger nullable

Optional concurrency override

intra_applier_concurrencyinteger nullable

Optional intra-applier concurrency override

source_task_sizeinteger nullable

Optional number of source row ids per work item during expansion. Bounds per-actor memory for chunker materialized views.

clusterstring nullable

Optional cluster name (operational override)

output_limitinteger nullable

Post-trim cap on view row count after expansion. Valid only for chunker materialized views; returns 400 if set on other kinds.

manifeststring nullable

Optional inline JSON-serialized GenevaManifest. Operational override for this refresh only; does not mutate the view's snapshotted manifest. When omitted, the manifest stored in the view's metadata is used.

Response

Refresh job accepted

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

job_idstring required

The job ID for tracking the refresh job