rust/lancedb
1
0
Fork 0
mirror of https://github.com/lancedb/lancedb.git synced 2026-10-12 14:52:26 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: leave a deployment's materialized view refresh mode to its version

Browse Source 
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.
This commit is contained in:
Brendan Clement
2026-10-08 21:42:20 -07:00
parent 34bfd03f4c
commit eedde82253
4 changed files with 16 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/web/feature-engineering/materialized-views.mdx
+9 -8
View File
@@ -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.
docs/web/sql/dml/copy.mdx
+1 -1
View File
@@ -7,7 +7,7 @@ keywords: ["copy", "export", "parquet", "sql"]
---
<Warning>
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.
</Warning>
docs/web/sql/dml/refresh.mdx
+4 -3
View File
@@ -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.
<Warning>
`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.
</Warning>
docs/web/sql/index.mdx
+2 -2
View File
@@ -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 |