mirror of
https://github.com/lancedb/lancedb.git
synced 2026-10-13 15:22:30 +00:00
docs: declare where four pages apply
Vector search, materialized view refresh, authentication and authorization now say in their frontmatter whether LanceDB OSS and LanceDB Enterprise have what they describe, with one sentence on how. The assembled site renders that as each page's label, its sidebar tag and its comparison row, so the hand-written badges and opening paragraphs on the two security pages go. The availability was checked against the SDK and the Enterprise server: authorization is enforced only on a deployment configured for it, and a deployment accepts OAuth tokens only with an identity provider configured. Sections now say that only the Rust SDK sets approx_mode, that a deployment may search exactly minimum_nprobes partitions, and that the SDK refuses with_no_data, like source_version, on a db:// connection.
This commit is contained in:
Brendan Clement
+22
-1
@@ -94,7 +94,7 @@ what the capability is, and what the embedded form does instead. A separate
|
||||
private repository supplies the fuller version of each, which replaces the page
|
||||
at the same path when the published site is assembled.
|
||||
|
||||
Two things to know before editing:
|
||||
Three things to know before editing:
|
||||
|
||||
**Code examples are not written into the pages.** They live in real tests under
|
||||
`docs/web-tests/{py,ts,rs}`, are extracted into `docs/web/snippets/`, and are
|
||||
@@ -116,6 +116,27 @@ Enterprise pages attach their additions to the right section, so they are
|
||||
assigned once and never regenerated. Leave an existing anchor alone even when
|
||||
you reword the heading above it; only new headings need a new one.
|
||||
|
||||
**A page can declare where it applies.** Its frontmatter says whether LanceDB
|
||||
OSS and LanceDB Enterprise have the feature -- `available`, `unavailable`, or
|
||||
`varies` when it depends on version or configuration -- and one sentence that
|
||||
says how:
|
||||
|
||||
```yaml
|
||||
availability:
|
||||
oss: unavailable
|
||||
enterprise: available
|
||||
summary: >-
|
||||
Requests to a deployment carry an API key or an OAuth token. Embedded
|
||||
LanceDB has no server to sign in to.
|
||||
```
|
||||
|
||||
The assembled site renders this as a label above the page's content, as a
|
||||
sidebar tag when only one offering has the feature, and as the page's row in
|
||||
the comparison on [OSS and Enterprise](docs/web/basics/offerings.mdx). Do not
|
||||
also open the page with a badge of its own, and keep a qualification that only
|
||||
one section needs in that section's text. A `mint dev` preview of `docs/web`
|
||||
alone renders neither the labels nor the comparison.
|
||||
|
||||
## Release process
|
||||
|
||||
For information on the release process, see: [release_process.md](release_process.md)
|
||||
|
||||
@@ -4,14 +4,15 @@ sidebarTitle: "Authentication"
|
||||
description: "Authentication modes for LanceDB Enterprise: API keys and OAuth credentials."
|
||||
icon: key
|
||||
keywords: ["authentication", "oauth", "api key", "azure managed identity", "client credentials"]
|
||||
availability:
|
||||
oss: unavailable
|
||||
enterprise: available
|
||||
summary: >-
|
||||
Requests to a deployment carry an API key or an OAuth token, whichever it is
|
||||
configured to accept. Embedded LanceDB has no server to sign in to; see
|
||||
[Architecture](/architecture).
|
||||
---
|
||||
|
||||
<Badge color="red">Enterprise</Badge>
|
||||
|
||||
This page describes a LanceDB Enterprise capability. The embedded form
|
||||
of LanceDB has no server to provide it -- see
|
||||
[Architecture](/architecture) for what differs between the two.
|
||||
|
||||
A deployment authenticates every request before
|
||||
[authorization](/governance/authorization) decides what it may do, against a
|
||||
`db://` remote table, in one of two ways:
|
||||
@@ -50,6 +51,10 @@ from an OIDC issuer and attach them to every request. Token acquisition,
|
||||
caching, and refresh are handled inside the client -- your application code
|
||||
only provides the configuration.
|
||||
|
||||
A deployment accepts these tokens only when its administrator has configured
|
||||
it with your identity provider. Ask them for the issuer URL, client ID and
|
||||
scopes to use.
|
||||
|
||||
<Info>
|
||||
In Python, OAuth is supported through `lancedb.connect_async`. The synchronous
|
||||
`connect` entry point continues to use API key authentication for `db://`
|
||||
|
||||
@@ -4,6 +4,13 @@ sidebarTitle: "Materialized View Refresh"
|
||||
description: "A lakehouse object: a table defined by a query over another table, brought up to date by each refresh."
|
||||
icon: table
|
||||
keywords: ["materialized view", "create_materialized_view", "refresh", "full refresh"]
|
||||
availability:
|
||||
oss: available
|
||||
enterprise: varies
|
||||
summary: >-
|
||||
The SDK creates and refreshes a local view in your process. On a deployment,
|
||||
views are off by default, and how they work depends on its version and
|
||||
configuration; see [Against a deployment](#availability).
|
||||
---
|
||||
|
||||
import {
|
||||
@@ -80,8 +87,8 @@ argument; every local refresh is a full one.
|
||||
`create_materialized_view` and `refresh` also work on a `db://` connection.
|
||||
There the SDK sends them to the deployment as SQL -- `CREATE MATERIALIZED VIEW`
|
||||
and `REFRESH MATERIALIZED VIEW` -- and the work runs on the cluster rather than
|
||||
in your process. `source_version` is for local views only; the SDK refuses it
|
||||
on a remote refresh.
|
||||
in your process. `with_no_data` and `source_version` are for local views only;
|
||||
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 refreshes a view -- rebuilding the whole view, as above,
|
||||
|
||||
@@ -4,15 +4,15 @@ sidebarTitle: "Authorization"
|
||||
description: "Who may do what: privileges granted on catalog objects to principals, groups, roles, and API keys."
|
||||
icon: shield-halved
|
||||
keywords: ["authorization", "authz", "privileges", "rbac", "access control"]
|
||||
availability:
|
||||
oss: unavailable
|
||||
enterprise: varies
|
||||
summary: >-
|
||||
A deployment checks privileges on its databases, namespaces and tables only
|
||||
when its administrator has configured it to. Embedded LanceDB has no such
|
||||
layer: access is whatever the object store allows.
|
||||
---
|
||||
|
||||
<Badge color="red">Enterprise</Badge>
|
||||
|
||||
This page describes a LanceDB Enterprise capability. Embedded LanceDB has no
|
||||
such layer -- access is whatever the object store enforces on the bucket or
|
||||
directory, which is coarser and has no concept of a table. See
|
||||
[Architecture](/architecture) for what differs between the two.
|
||||
|
||||
[Authentication](/enterprise/authentication) establishes who is calling.
|
||||
Authorization decides what they may do.
|
||||
|
||||
|
||||
@@ -3,6 +3,13 @@ title: "Vector Search"
|
||||
sidebarTitle: "Vector Search"
|
||||
description: "Learn how to run vector search queries in LanceDB. Includes best practices, tips and examples."
|
||||
icon: "arrow-up-right-dots"
|
||||
availability:
|
||||
oss: available
|
||||
enterprise: available
|
||||
summary: >-
|
||||
Vector search runs in the embedded library and on a deployment. A few query
|
||||
options depend on the SDK or on the deployment's version; their sections
|
||||
say so.
|
||||
---
|
||||
|
||||
import {
|
||||
@@ -208,7 +215,7 @@ The supported values are:
|
||||
| `normal` | Use the default balance between query latency and recall. This only has an effect for RQ indexes built with `num_bits > 1`. |
|
||||
| `accurate` | Prefer higher recall, which can increase query latency. |
|
||||
|
||||
You can change `approx_mode` per query without rebuilding the index. For RQ indexes built with `num_bits=1`, `normal` uses the same one-bit scoring path as `fast`. If you also set `refine_factor`, LanceDB first uses `approx_mode` while finding candidates, then reranks the selected candidates on full vectors.
|
||||
Only the Rust SDK sets `approx_mode`; the Python and TypeScript SDKs do not expose it. You can change `approx_mode` per query without rebuilding the index. For RQ indexes built with `num_bits=1`, `normal` uses the same one-bit scoring path as `fast`. If you also set `refine_factor`, LanceDB first uses `approx_mode` while finding candidates, then reranks the selected candidates on full vectors.
|
||||
|
||||
### Tuning `nprobes`
|
||||
|
||||
@@ -223,6 +230,8 @@ You can change `approx_mode` per query without rebuilding the index. For RQ inde
|
||||
For filtered ANN searches, you can also set `minimum_nprobes` and `maximum_nprobes`. LanceDB starts
|
||||
with the minimum and can scan more partitions up to the maximum if the filter leaves too few
|
||||
candidates. Calling `nprobes(n)` fixes both values to `n`, which disables that adaptive behavior.
|
||||
Whether a deployment honors this range depends on its version; one that does not searches exactly
|
||||
`minimum_nprobes` partitions.
|
||||
|
||||
### Vector Search with Prefiltering
|
||||
|
||||
|
||||
Reference in New Issue
Block a user