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.
This commit is contained in:
Brendan Clement
2026-10-05 14:12:12 -07:00
parent 69f11c259d
commit 6367f7a0de
6 changed files with 45 additions and 34 deletions
+4 -3
View File
@@ -25,9 +25,10 @@ REFRESH COLUMN doubled ON my_table
REFRESH COLUMN embedding ON documents WHERE created_at > '2026-01-01'
```
A refresh gives values to rows that lack them and **leaves filled rows alone**.
That makes it idempotent, cheap to repeat as data arrives, and resumable after a
failure -- re-running costs only the rows that did not complete.
A refresh gives values to rows that lack them, recomputes rows whose inputs
changed, and **leaves other filled rows alone**. That makes it idempotent, cheap
to repeat as data arrives, and safe to re-run after a failure -- though a re-run
can recompute values the failed run had already written.
`WHERE` scopes the refresh, which is how you fill a slice and check it before
committing to the whole table.
+3 -2
View File
@@ -18,8 +18,9 @@ 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. A filled value keeps what it was
computed from -- see [Guarantees](/basics/guarantees#jobs).
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