v1

latestOpenAPI 3.1.1Apache 2.02026-07-2654130166.5 KB

MaterializedView

Data

Create a materialized view

Create a materialized view at identifier id. The view may be query-backed, UDTF-backed, or chunker-backed, controlled by the kind discriminator.

post/v1/materialized_view/{id}/create

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[]

View identifier path (namespace + view name)

kind'query' | 'udtf' | 'chunker' required

The materialized view kind.

query — plain query-backed view (no UDTF), 1:1 rows.
udtf — batch UDTF-backed view (N:M rows, full refresh).
chunker, aka 'scalar_udtf' — chunker view (1:N row expansion, incremental refresh).

source_querystring required

Opaque serialized representation of the source query that defines the view's input. The format is defined by the client; the namespace server stores it without interpreting it.

output_schemastring required

Base64-encoded Arrow schema of the view output

with_no_databoolean

If false, the server kicks off an initial refresh immediately after creating the view and the response includes a job ID.

auto_refreshboolean nullable

If true, the view is automatically refreshed when source-table data changes past the deployment-level threshold. Boolean opt-in only; the threshold and cooldown are configured on the deployment, not per-view.

Response

Materialized view created

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

versioninteger required

The commit version that created the materialized view

job_idstring nullable

Refresh job ID, populated only when with_no_data was false.

All 54 operations