mirror of
https://github.com/lancedb/lancedb.git
synced 2026-10-13 15:22:30 +00:00
Jack Ye
5b5ed930ac
Every group now answers exactly one question. Get started and Concepts cover what the system is; the verb groups cover doing something with it; Operate, Secure and Deploy cover running it; SQL reference is lookup. Maintenance becomes Operate, Governance becomes Secure, and the rest take verbs to match. Three new pages in Concepts and Get started: Guarantees states what a write promises when it returns, which version a reader sees, what survives a failure, and -- the half usually missing -- what is not guaranteed: no multi-table transactions, no read-your-writes across processes without an interval, unenforced primary keys that do not enforce, no background compaction. Limits collects bounds that were stated in passing across a dozen pages, with the numbers verified against the code rather than inferred: name lengths, job event caps, SHOW ERRORS bounds, the sampling range that is refused rather than clamped. Architecture illustrates embedded against distributed as the one deployment decision, and is written to cover both rather than only Enterprise. Indexing splits by question. Choosing an index is a Query decision and moves there; building, repairing and GPU-building it stay in Operate. SQL becomes a top-level reference of fifteen pages instead of a sub-group of Query. Auditing sophon-sql turned up a large undocumented surface: ALTER TABLE ADD COLUMN in its plain, computed and function forms with FILTER, IGNORE NULLS and OVER modifiers; SET UNENFORCED PRIMARY KEY; SET and UNSET WAL with sharding; CREATE FUNCTION with its dependency options; REFRESH COLUMN and REFRESH MATERIALIZED VIEW; and the SHOW family. None of it was written down.
82 lines
2.4 KiB
Plaintext
82 lines
2.4 KiB
Plaintext
---
|
|
title: "DML"
|
|
sidebarTitle: "DML"
|
|
description: "INSERT, UPDATE, DELETE and COPY — changing the rows a table holds."
|
|
icon: pen-to-square
|
|
keywords: ["insert", "update", "delete", "copy", "dml"]
|
|
---
|
|
|
|
<Badge color="red">Enterprise</Badge> [SQL runs on a deployment.](/sql)
|
|
|
|
Statements that change rows. For the shape of the table, see [DDL](/sql/ddl).
|
|
|
|
Each of these commits a new table version, so
|
|
[versioning](/tables/versioning) and the
|
|
[write guarantees](/basics/guarantees#writes) apply -- including that the
|
|
version advances even when a statement affects zero rows.
|
|
|
|
## INSERT {#insert}
|
|
|
|
```sql
|
|
INSERT INTO documents (id, title) VALUES (1, 'Merlin'), (2, 'Arthur')
|
|
|
|
INSERT INTO archive SELECT * FROM documents WHERE created_at < '2026-01-01'
|
|
```
|
|
|
|
`INSERT ... SELECT` is the form worth knowing: it moves rows between tables
|
|
server-side, without a round trip through your process.
|
|
|
|
## UPDATE {#update}
|
|
|
|
```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. A filled value keeps what it was
|
|
computed from -- see [Guarantees](/basics/guarantees#jobs).
|
|
</Warning>
|
|
|
|
## DELETE {#delete}
|
|
|
|
```sql
|
|
DELETE FROM documents WHERE created_at < '2025-01-01'
|
|
```
|
|
|
|
Deletion marks rows rather than erasing them, so the data remains recoverable
|
|
for as long as the version holding it survives
|
|
[retention](/maintenance/compaction).
|
|
|
|
## COPY {#copy}
|
|
|
|
```sql
|
|
COPY (SELECT id, title FROM documents) TO 's3://bucket/export/' STORED AS PARQUET
|
|
```
|
|
|
|
Writes a query result to object storage. This is the export path when the
|
|
consumer is another engine rather than an application -- results land as files
|
|
rather than streaming to a client.
|
|
|
|
## Merge insert {#merge-insert}
|
|
|
|
Upsert -- matching incoming rows against existing keys -- has no SQL form. It is
|
|
an SDK operation, because it needs a source relation and a per-match policy that
|
|
a single statement cannot express. See
|
|
[Merge insert](/ingestion/merge-insert).
|
|
|
|
## See also {#see-also}
|
|
|
|
<CardGroup cols={2}>
|
|
<Card title="Ingestion" icon="inbox" href="/ingestion">
|
|
The same operations from the SDKs.
|
|
</Card>
|
|
<Card title="DDL" icon="pen-ruler" href="/sql/ddl">
|
|
Changing structure rather than rows.
|
|
</Card>
|
|
</CardGroup>
|