v52

latestOpenAPI 3.1.1Apache 2.0raw.githubusercontent.com2026-08-0354155395.9 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

Path parameters

idstring required

string identifier of an object in a namespace, following the Lance Namespace spec. When the value is equal to the delimiter, it represents the root namespace. For example, v1/namespace/$/list performs a ListNamespace on the root namespace.

Query parameters

delimiterstring

An optional delimiter of the string identifier, following the Lance Namespace spec. When not specified, the $ delimiter must be used.

Request body

{"stackTrail":"components:schemas:CreateMaterializedViewRequest:properties:context","oasType":"schema","type":"unknown","description":"Arbitrary context as key-value pairs.\nHow to use the context is custom to the specific implementation.\n\nOn a request, it carries caller-provided context to the implementation.\nOn a response, it carries implementation-provided context back to the caller.\n\nREST NAMESPACE ONLY\nContext entries are mapped to and from HTTP headers using the `header.` prefix:\n- On a request, any entry whose key starts with `header.` is sent as an HTTP\n request header with the prefix stripped. For example, the entry\n `{\"header.Authorization\": \"Bearer abc\"}` is sent as the request header\n `Authorization: Bearer abc`.\n- On a response, every HTTP response header is returned as an entry whose key is the\n header name prefixed with `header.`. For example, the response header\n `x-request-id: abc123` is returned as the entry `{\"header.x-request-id\": \"abc123\"}`.\n"}
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.

Example request

{
  "auto_refresh": false,
  "source_query": "source_query",
  "identity": {
    "api_key": "api_key",
    "auth_token": "auth_token"
  },
  "kind": "query",
  "udtf_spec": {
    "num_cpus": 0.8008281904610115,
    "udtf_name": "udtf_name",
    "memory": 1,
    "partition_by_indexed_column": "partition_by_indexed_column",
    "num_gpus": 6.027456183070403,
    "kind": "udtf",
    "manifest": "manifest",
    "batch": true,
    "error_handling": "{}",
    "udtf_version": "udtf_version",
    "partition_by": "partition_by",
    "manifest_checksum": "manifest_checksum",
    "udtf": "udtf",
    "input_columns": [
      "input_columns",
      "input_columns"
    ],
    "udtf_sha": "udtf_sha"
  },
  "context": {
    "key": "context"
  },
  "with_no_data": true,
  "id": [
    "id",
    "id"
  ],
  "output_schema": "output_schema"
}

Response

Materialized view created

{"stackTrail":"components:schemas:CreateMaterializedViewResponse:properties:context","oasType":"schema","type":"unknown","description":"Arbitrary context as key-value pairs.\nHow to use the context is custom to the specific implementation.\n\nOn a request, it carries caller-provided context to the implementation.\nOn a response, it carries implementation-provided context back to the caller.\n\nREST NAMESPACE ONLY\nContext entries are mapped to and from HTTP headers using the `header.` prefix:\n- On a request, any entry whose key starts with `header.` is sent as an HTTP\n request header with the prefix stripped. For example, the entry\n `{\"header.Authorization\": \"Bearer abc\"}` is sent as the request header\n `Authorization: Bearer abc`.\n- On a response, every HTTP response header is returned as an entry whose key is the\n header name prefixed with `header.`. For example, the response header\n `x-request-id: abc123` is returned as the entry `{\"header.x-request-id\": \"abc123\"}`.\n"}
versioninteger required

The commit version that created the materialized view

job_idstring nullable

Refresh job ID, populated only when with_no_data was false.

Example response

{
  "job_id": "job_id",
  "context": {
    "key": "context"
  },
  "version": 0
}