mirror of
https://github.com/lancedb/lancedb.git
synced 2026-10-12 14:52:26 +00:00
Jack YeandBrendan Clement
47b7babc08
Move the public website pages into `docs/web` beside the SDK, with
shared navigation and executable example sources in `docs/web-tests`.
The combined website is assembled by
[lancedb/docs#355](https://github.com/lancedb/docs/pull/355), with six
Enterprise replacements from
[lancedb/sophon#7681](https://github.com/lancedb/sophon/pull/7681).
This includes Function guidance, runnable Quickstarts, regenerated
snippets, production contact/demo fixes, the legacy SQL route, and the
LeRobot redirect. LeRobot remains attributed to Geneva; all 34 Geneva
pages remain in the docs repository until Function officially launches.
Materialized-view guidance follows the full rebuild refresh introduced
by #4373: local refresh writes the complete result, has no `full`
argument, supports `source_version`, and no longer requires stable row
IDs. Deployment SQL refresh options and stable-ID setup are qualified by
version/configuration. Function input guidance distinguishes ordinary
stored columns from computed inputs supported by newer deployments.
**Validation:** independently accepted local checks include 95 Python
tests (real Enterprise excluded), eight TypeScript tests, Rust
Quickstart, snippet parity, typos, deterministic assembly, Mint
validation and links/anchors/redirects. The combined baseline retains
all 181 production routes and 17 legacy redirects. Examples ran locally
against source-built Python SDK 0.40.0b13; existing GitHub workflows do
not run `docs/web-tests`. New main at `069b2f7d` is 0.41.0b0 and adds
computed Function inputs; that SDK was not exercised by the accepted
tests. Latest prose corrections receive focused site validation.
**Merge/rollout:** merge this and #7681 before #355's combined CI, which
reads producer `main`. This is migration infrastructure: section
overlays, source-owned skills and automatic versioned paired releases
remain follow-ups. The current manual publisher is transitional. Hosted
validation, a supported SDK/Enterprise release pair and a real
Enterprise walkthrough remain pending.
Production Mintlify watches `lancedb/docs:deploy-freeze`, directory
`docs`; preserve that source through review. The separate SDK GitHub
Pages reference workflow rebuilds on main merges.
**Updated-head CI (9a50f8db):**
[Typos](https://github.com/lancedb/lancedb/actions/runs/37654185443/job/112904990558),
[PR
title](https://github.com/lancedb/lancedb/actions/runs/37654179507/job/112904974595)
and
[Aikido](https://app.aikido.dev/featurebranch/scan/215386145?groupId=74229)
pass. Critical findings in the example lockfiles were patched: all Sharp
copies use 0.35.5, protobufjs 7.6.6, tar 7.5.22, quinn-proto 0.11.19,
zerovec 0.11.8 and zerovec-derive 0.11.6. The SDK's product dependencies
are unchanged. The revised lockfiles pass eight TypeScript examples,
HuggingFace decode/resize/crop/rescale/normalize plus AVIF roundtrip,
and Rust Quickstart. Aikido passing does not mean every advisory is
cleared; npm still reports 29 high and five moderate advisories in the
example dependency graph. No scanner bypass or suppression was added.
The Function prose correction passes combined/standalone Mint,
deterministic assembly, routes and assets. The revised 325-file site
checksum is
`175bec06864abb400dd292e667ba93448c0479b8359fd7bf6146afabf9040647`. This
PR remains open for independent review; further merges are on hold.
---------
Co-authored-by: Brendan Clement <brendan.clement@lancedb.com>
66 lines
2.5 KiB
Plaintext
66 lines
2.5 KiB
Plaintext
---
|
|
title: "Prepared statements"
|
|
sidebarTitle: "Prepared Statements"
|
|
description: "Preparing a statement once and executing it many times, over the Flight SQL protocol."
|
|
icon: bolt
|
|
keywords: ["prepared statement", "flight sql", "parameters", "bind"]
|
|
---
|
|
|
|
<Badge color="red">Enterprise</Badge> [SQL runs on a deployment.](/sql)
|
|
|
|
A prepared statement is planned once and executed many times, which saves
|
|
re-planning a statement whose shape does not change between runs.
|
|
|
|
## It is a protocol feature, not a statement {#protocol}
|
|
|
|
<Warning>
|
|
There is no SQL `PREPARE` / `EXECUTE` here. Preparation is part of the
|
|
**Arrow Flight SQL protocol**, so you reach it through your client rather than
|
|
by sending a statement.
|
|
</Warning>
|
|
|
|
That distinction matters when porting SQL from another engine: a script
|
|
containing `PREPARE name AS SELECT ...` will not run, while the same intent
|
|
expressed through a Flight SQL client will.
|
|
|
|
## The flow {#flow}
|
|
|
|
Every Flight SQL client exposes the same three steps, whatever it calls them:
|
|
|
|
1. **Prepare** — send the SQL, get back a handle and the result schema. The
|
|
statement is parsed and planned at this point, so a syntax or name error
|
|
surfaces here rather than at execution.
|
|
2. **Bind and execute** — supply parameter values for the handle and read the
|
|
result. Repeat as often as you like.
|
|
3. **Close** — release the handle. Servers do not hold them forever.
|
|
|
|
Knowing that the plan is built at step 1 is the practical part: if a statement
|
|
is slow to prepare and fast to execute, the cost is planning, and reusing the
|
|
handle is exactly the right fix.
|
|
|
|
## Parameters {#parameters}
|
|
|
|
Parameters are placeholders in the SQL text, bound to an Arrow record batch at
|
|
execution. Binding rather than interpolating is worth doing for the usual two
|
|
reasons — the value cannot change the statement's meaning, and the plan is
|
|
reused across values.
|
|
|
|
```sql
|
|
SELECT id, title FROM documents WHERE category = $1 AND score > $2
|
|
```
|
|
|
|
The exact placeholder spelling and the binding call belong to your client; see
|
|
[connecting a client](/sql#connecting).
|
|
|
|
## When it helps {#when}
|
|
|
|
| | |
|
|
| --- | --- |
|
|
| The same query with different values, many times | prepare once, bind per execution |
|
|
| A complex plan — several joins, window functions | planning dominates; reuse it |
|
|
| A one-off analytical query | no benefit; just execute it |
|
|
|
|
For a statement you want to keep rather than re-prepare, a
|
|
[view](/management/view) stores the query server-side, and a
|
|
[materialized view](/management/materialized-view) stores its rows.
|