Initiates the process of creating a materialized view, reserving the view’s
name to prevent other views or tables from being created with that name.For materialized view details and examples, see
Materialized Views.The response contains output parameter view_id, which is used to tag each
subsequent operation (projection, union, aggregation, filter, or join) that
will compose the view.
Name of the table to be created that is the top-level table of the materialized view, in [schema_name.]table_name format, using standard name resolution rules and meeting table naming criteria.
[DEPRECATED—please specify the containing schema for the materialized view as part of input parameter table_name and use /create/schema to create the schema if non-existent] Name of a schema which is to contain the newly created view. If the schema provided is non-existent, it will be automatically created.
If true, then the materialized view specified in input parameter table_name will be persisted and will not expire unless a ttl is specified. If false, then the materialized view will be an in-memory table and will expire unless a ttl is specified otherwise.The default value is false.The supported values are:
When refresh_method is periodic, specifies the time at which a periodic refresh is stopped. Value is a datetime string with format ‘YYYY-MM-DD HH:MM:SS’.
Method by which the join can be refreshed when the data in underlying member tables have changed.The default value is manual.
manual: Refresh only occurs when manually requested by calling /alter/table with an ‘action’ of ‘refresh’.
on_query: Refresh any time the view is queried.
on_change: If possible, incrementally refresh (refresh just those records added) whenever an insert, update, delete or refresh of input table is done. A full refresh is done if an incremental refresh is not possible.
periodic: Refresh table periodically at rate specified by refresh_period.
When refresh_method is periodic, specifies the first time at which a refresh is to be done. Value is a datetime string with format ‘YYYY-MM-DD HH:MM:SS’.
The Kinetica server embeds the endpoint response inside a standard response structure which contains status information and the actual response to the query. Here is a description of the various fields of the wrapper:
