Querying & DML
KalamClient.query(...) executes SQL over the KalamDB HTTP API and returns a QueryResponse.
Parameterized queries
Use $1, $2, … placeholders in SQL and pass params as a Dart list.
params is encoded to JSON and sent to the server, so values should be JSON-compatible (strings, numbers, booleans, null, lists, and maps).
If you need richer server-side typing (timestamps, decimals, JSON columns), keep your SQL explicit (e.g. CAST(...)) and validate the returned values.
Namespaces
KalamDB supports per-tenant namespaces. The SDK exposes this as an optional namespace argument.
This is most useful when your SQL references unqualified tables (e.g. messages instead of alice.messages).
For background, see: SQL Reference: Namespaces.
Reading results
A QueryResponse can contain multiple QueryResult values (one per statement). The most common pattern is to read the first one.
Primary row access (QueryResult.rows)
rows is List<Map<String, KalamCellValue>> (named columns), not List<List<dynamic>>.
Multiple statements
DML: INSERT / UPDATE / DELETE
All SQL goes through query(...):
FILE refs: insert and read
Insert a FILE reference value
If you already have file metadata (for example from a previous read), insert it as JSON:
Read a FILE reference
getDownloadUrl(...) delegates to the shared Rust link-common FileRef
model, the same source used by the TypeScript SDK. The returned path is:
Fetch the URL with the authenticated user’s bearer token. For user tables, SDK
helpers generate an owner-scoped URL: regular users can download only their own
files. Service clients can upload/write through authorized EXECUTE AS USER
flows, but direct cross-user FILE byte downloads require a dba or system
token and an authorized user_id query parameter.
Error handling
When success is false, the server returns an error code/message:
For user-facing apps, prefer mapping error.code to a stable UI message and logging error.details for debugging.