Files
lancedb/docs/web/sql/dml/update.mdx
T
Brendan Clement 6367f7a0de docs: describe refresh and retries the same way on every page
Five pages still said a refresh never revisits a filled row and that a
changed input needs the column dropped and declared again. Since
lancedb#4161 a refresh also recomputes rows whose inputs changed, so the
quickstart, the feature-engineering overview, Guarantees, and the SQL
REFRESH and UPDATE pages now say that.

Retry claims are qualified the same way. A local refresh commits the column
once, and a deployment's job commits finished batches. A retry fills what is
still empty or stale, but can recompute values that were already written (a
refresh whose input record was not saved recomputes next time), so no page
promises that a retry costs only the unfinished rows.
2026-10-05 14:12:12 -07:00

35 lines
1.1 KiB
Plaintext

---
title: "Update"
sidebarTitle: "Update"
description: "UPDATE ... SET ... WHERE — and why it does not recompute derived columns."
icon: pen
keywords: ["update", "sql"]
---
<Badge color="red">Enterprise</Badge> [SQL runs on a deployment.](/sql)
```sql
UPDATE documents SET title = upper(title) WHERE category = 'film'
```
Assignments take any expression the [dialect](/sql/functions) supports,
including references to other columns of the same row. Without a `WHERE`
clause every row is updated.
<Warning>
An update does not recompute [computed columns](/feature-engineering/add-computed-column)
that derive from the column you changed. Those rows keep the value computed from
the old input until the next refresh recomputes them -- see
[Guarantees](/basics/guarantees#jobs).
</Warning>
Commits a new table version, so [versioning](/management/table#versioning) and
the [write guarantees](/basics/guarantees#writes) apply -- including that the
version advances even when the statement affects zero rows.
## What to read next {#next}
<Card title="Update" icon="pen" href="/ingestion/update">
The SDK equivalent.
</Card>