From eedde8225306f4f03ff1b76eefa8c0150d077705 Mon Sep 17 00:00:00 2001 From: Brendan Clement Date: Thu, 8 Oct 2026 21:42:20 -0700 Subject: [PATCH] docs: leave a deployment's materialized view refresh mode to its version Sophon main now refreshes an eligible materialized view incrementally, appending what an append-only source added since the last refresh, a day after the change that made every refresh a full rebuild. So the materialized view page and the REFRESH reference no longer say recent versions rebuild in full: they say recent versions run views as SQL jobs, need no stable row ids and take no refresh options, and that a full or incremental refresh depends on the version and the view's query. COPY is described with the same "recent versions" wording. --- .../feature-engineering/materialized-views.mdx | 17 +++++++++-------- docs/web/sql/dml/copy.mdx | 2 +- docs/web/sql/dml/refresh.mdx | 7 ++++--- docs/web/sql/index.mdx | 4 ++-- 4 files changed, 16 insertions(+), 14 deletions(-) diff --git a/docs/web/feature-engineering/materialized-views.mdx b/docs/web/feature-engineering/materialized-views.mdx index cc807f0db..3e8019c5f 100644 --- a/docs/web/feature-engineering/materialized-views.mdx +++ b/docs/web/feature-engineering/materialized-views.mdx @@ -92,20 +92,21 @@ the SDK refuses them on a `db://` connection. Materialized views are off by default on a deployment and have to be enabled there. How a deployment handles a view then depends on its LanceDB Enterprise -version. Newer versions run every create and refresh as a job that rebuilds the -whole view, as a local refresh does; the source does not need stable row ids, -and [`REFRESH MATERIALIZED VIEW`](/sql/dml/refresh#refresh-materialized-view) -accepts no options. Earlier versions could instead reconcile only what changed -in the source, and could require the source to have stable row ids. A view -created by an earlier version has to be recreated once the deployment moves to -a newer one. +version. Recent versions create and refresh every view as a SQL job: the source +does not need stable row ids, +[`REFRESH MATERIALIZED VIEW`](/sql/dml/refresh#refresh-materialized-view) takes +no options, and whether a refresh rebuilds the whole view, as a local refresh +does, or adds only what changed in the source depends on the version and on the +view's query. Earlier versions could require the source to have stable row ids +and took refresh options; a view they created has to be recreated once the +deployment moves to a recent version. Stable row ids are set up on the deployment, not by the SDK: a `db://` connection does not send `new_table_enable_stable_row_ids`, and no SDK call adds them to an existing table. An earlier version that requires them may give new tables stable row ids, may refuse a view created through SQL -- as the SDK creates one -- over a source without them, or may convert an existing source -when a view is created through its REST API, which newer versions no longer +when a view is created through its REST API, which recent versions no longer have. Check with the deployment's administrator which version it runs before relying on a source. diff --git a/docs/web/sql/dml/copy.mdx b/docs/web/sql/dml/copy.mdx index 3fe002fe8..658b20b59 100644 --- a/docs/web/sql/dml/copy.mdx +++ b/docs/web/sql/dml/copy.mdx @@ -7,7 +7,7 @@ keywords: ["copy", "export", "parquet", "sql"] --- -Newer deployment versions refuse `COPY` over the SQL endpoint with "COPY is not +Recent deployment versions refuse `COPY` over the SQL endpoint with "COPY is not supported". On those, export a result by reading it through a Flight SQL client or an SDK and writing the files from your application. diff --git a/docs/web/sql/dml/refresh.mdx b/docs/web/sql/dml/refresh.mdx index 4882c86ed..90ba61c8f 100644 --- a/docs/web/sql/dml/refresh.mdx +++ b/docs/web/sql/dml/refresh.mdx @@ -71,13 +71,14 @@ REFRESH MATERIALIZED VIEW chunks WITH (full = true) On earlier deployment versions, `full = true` asks for every row to be recomputed, and without it a refresh can reconcile only what changed in the -source. Newer versions rebuild the whole view on every refresh, as every local -SDK refresh does, and refuse `WITH` options. +source. Recent versions refuse `WITH` options; whether their refresh rebuilds +the whole view, as every local SDK refresh does, or adds only what changed +depends on the version and on the view's query. `CASCADE` asks for the views this one is built on to be refreshed first, in dependency order. Whether a deployment carries it out depends on its version, -and newer versions refuse it; where it is refused, refresh each view yourself, +and recent versions refuse it; where it is refused, refresh each view yourself, its sources first. diff --git a/docs/web/sql/index.mdx b/docs/web/sql/index.mdx index 4b92ef38c..6b147d0a7 100644 --- a/docs/web/sql/index.mdx +++ b/docs/web/sql/index.mdx @@ -111,7 +111,7 @@ operations that have no SQL form, such as a merge insert -- see | [Insert](/sql/dml/insert) | `INSERT INTO`, including `INSERT ... SELECT` | | [Update](/sql/dml/update) | `UPDATE ... SET` | | [Delete](/sql/dml/delete) | `DELETE FROM` | -| [Copy](/sql/dml/copy) | `COPY` -- refused by newer deployment versions | +| [Copy](/sql/dml/copy) | `COPY` -- refused by recent deployment versions | | [Refresh](/sql/dml/refresh) | filling computed columns and materialized views | ### DQL {#dql} @@ -144,7 +144,7 @@ operations that have no SQL form, such as a merge insert -- see | Vector search | [depends on the deployment](/basics/sql#no-vector-sql); the query builder always has it | | Merge insert | no SQL form -- needs a source relation and a per-match policy | | `information_schema` | not enabled, so `SHOW TABLES` and `SHOW COLUMNS` fail | -| `COPY` | refused by newer deployment versions -- see [Copy](/sql/dml/copy) | +| `COPY` | refused by recent deployment versions -- see [Copy](/sql/dml/copy) | | `PREPARE` / `EXECUTE` | preparation is a [protocol feature](/sql/prepared-statements), not a statement | | Run on a local database | no engine to plan the statement |