docs: correct the labelled pages against the pinned deployment

Authorization wrote objects as namespace:db/ns and table:db/ns/table,
which the deployment rejects; it writes namespace:db:ns and
table:db:ns$table, nesting namespaces with $. The page now lists the
view, function and secret objects, CREATE_FUNCTION and CREATE_SECRET,
USAGE and UPDATE where they apply beyond tables, and what OPERATE and
USAGE on system allow. An a: subject names the principal holding a key
rather than a narrower grantee, creation falls back to the parent's
create privilege only for an unowned database or namespace, and a
listing page holds at most 100 entries.

The materialized view page said a deployment's refresh, options and
stable row id needs depend on version and configuration. Newer versions
rebuild the whole view on every create and refresh as a job, need no
stable row ids, take no refresh options, and have no REST route to create
one; earlier ones differed, and their views have to be recreated. The
page and the REFRESH reference now say so, without naming which version
a deployment runs.

Vector search no longer says it has no SQL form: some deployment
versions plan ORDER BY distance(...) LIMIT k as one.
This commit is contained in:
Brendan Clement
2026-10-08 21:31:15 -07:00
parent f228295c34
commit 05c7ba4889
4 changed files with 65 additions and 41 deletions
+7 -6
View File
@@ -69,15 +69,16 @@ REFRESH MATERIALIZED VIEW chunks
REFRESH MATERIALIZED VIEW chunks WITH (full = true)
```
`full = true` asks for every row to be recomputed. Without it, whether a
refresh rebuilds the whole view -- as every local SDK refresh does -- or
reconciles only what changed in the source depends on the deployment's LanceDB
Enterprise version and configuration.
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.
<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;
where it does not, refresh each view yourself, its sources first.
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,
its sources first.
</Warning>
## Watching a refresh {#watching}