dirsql 0.4.60__tar.gz → 0.4.62__tar.gz

{dirsql-0.4.60 → dirsql-0.4.62}/Cargo.lock

@@ -552,7 +552,7 @@ checksum = "6184e33543162437515c2e2b48714794e37845ec9851711914eec9d308f6ebe8"
 
 [[package]]
 name = "dirsql"
-version = "0.4.60"
+version = "0.4.62"
 dependencies = [
  "assert_cmd",
  "axum",
@@ -585,7 +585,6 @@ dependencies = [
  "tokio-stream",
  "toml",
  "typed-path",
- "walkdir",
 ]
 
 [[package]]
@@ -601,7 +600,7 @@ dependencies = [
 
 [[package]]
 name = "dirsql-py-ext"
-version = "0.4.60"
+version = "0.4.62"
 dependencies = [
  "dirsql",
  "pyo3",

{dirsql-0.4.60 → dirsql-0.4.62}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dirsql
-Version: 0.4.60
+Version: 0.4.62
 Requires-Dist: bin-shim>=0.1
 Summary: Ephemeral SQL index over a local directory
 Keywords: sql,filesystem,directory,sqlite,index

{dirsql-0.4.60 → dirsql-0.4.62}/docs/getting-started.md

@@ -81,11 +81,15 @@ The first run downloads the package (`npx` asks for confirmation — answer
 `y`; `uvx` prints download progress), then prints the result:
 
 ```
-[{"files":3}]
+files
+-----
+3
+
+1 row
 ```
 
 Three files, three rows. That one command scanned the directory, handed
-SQLite one row per file, ran your SQL, and printed the answer as JSON.
+SQLite one row per file, ran your SQL, and printed the answer.
 
 There is no named table here — you never declared one. `'./'` is a
 [path-table](./reference/path-tables.md): a quoted path written where a table
@@ -94,8 +98,9 @@ in. The path *is* the query.
 
 ## 3. Select some columns
 
-The response is always a JSON array of row objects, so from here on we pipe
-it through `jq` to pretty-print. Ask for two columns instead of a count:
+At a terminal `dirsql` prints a table; when its output is piped, it prints a
+JSON array of row objects instead. From here on we pipe it through `jq` to
+pretty-print. Ask for two columns instead of a count:
 
 ::: code-group
 

{dirsql-0.4.60/packages/rust → dirsql-0.4.62}/docs/howto/write-a-plugin.md

@@ -60,11 +60,12 @@ its `embed()` SQL function),
 and [`ignore`](../reference/config.md#dirsql-keys).
 
 There are **no plugin-specific keys and no plugin-specific restrictions**. The
-config schema is content-only: the index `root` and `--persist` are
-[runner-owned flags](../reference/config.md#dirsql-keys) (`--root`, `--persist
-[PATH]`), decided by whoever runs `dirsql`, never by a config file — so a
-plugin has nothing to say about them. Whatever you can put in your own
-`.dirsql.toml`, a plugin can put in its fragment, and vice-versa.
+config schema is content-only: the index root and persistence are
+[runner-owned](../reference/config.md#dirsql-keys) — the root is the directory
+`dirsql` is run from (or an SDK's explicit `root`), persistence is the
+`--persist [PATH]` flag — decided by whoever runs `dirsql`, never by a config
+file, so a plugin has nothing to say about them. Whatever you can put in your
+own `.dirsql.toml`, a plugin can put in its fragment, and vice-versa.
 
 ## Hook commands
 

{dirsql-0.4.60/packages/rust → dirsql-0.4.62}/docs/plugins.md

@@ -93,9 +93,10 @@ scope.
 ### Vector cache
 
 Computed vectors are cached at `~/.cache/dirsql/embeddings/` (respecting
-`XDG_CACHE_HOME`), keyed on the SHA-256 of the value bytes plus the model
-identifier. Changing either recomputes — switching models never serves stale
-vectors — and re-running a query over unchanged files is cache hits all the
-way. There is no eviction: the directory is **safe to wipe at any time**; the
-only cost is re-embedding. The cache never lives inside a queried tree — the
-worker writes nothing into the directories you query.
+`XDG_CACHE_HOME`): one SQLite database per model identifier, each row keyed
+on the SHA-256 of the value bytes. Changing the value or the model recomputes
+— switching models never serves stale vectors — and re-running a query over
+unchanged files is cache hits all the way, a whole batch answered by one
+query. There is no eviction: the directory is **safe to wipe at any time**;
+the only cost is re-embedding. The cache never lives inside a queried tree —
+the worker writes nothing into the directories you query.

{dirsql-0.4.60 → dirsql-0.4.62}/docs/reference/cli.md

@@ -1,11 +1,13 @@
 # CLI
 
-Query is the default: `dirsql "<sql>"` runs one query and prints JSON rows.
+Query is the default: `dirsql "<sql>"` runs one query and prints the rows —
+a table at a terminal, a JSON array when piped (see
+[Output format](#output-format)).
 The `dirsql` binary has these modes:
 
 | Invocation | Behavior |
 |---|---|
-| `dirsql "<sql>"` | Run one query over the directory and print the rows as JSON. The default; identical to `dirsql query "<sql>"`. |
+| `dirsql "<sql>"` | Run one query over the directory and print the rows. The default; identical to `dirsql query "<sql>"`. |
 | `dirsql query "<sql>"` | Explicit synonym for the default one-shot query. |
 | `dirsql server` | Start a long-lived HTTP server exposing a SQL view of a directory. See [HTTP API](./http-api.md). |
 | `dirsql init` | Generate a `.dirsql.toml`. |
@@ -53,7 +55,7 @@ pipeline, same flags, same output. See that section for config discovery,
 
 ```bash
 dirsql
-# dirsql 0.2.7 — this directory is a database.
+# dirsql <version> — this directory is a database.
 #
 #   SELECT basename, size FROM './' ORDER BY size DESC LIMIT 5;
 #   SELECT path FROM './**/*.md' WHERE content LIKE '%TODO%';
@@ -331,9 +333,10 @@ is a hard error — `error: the subcommand 'query' cannot be used with
 for the server they follow the subcommand: `dirsql server -c <cfg>`.)
 :::
 
-The subcommand builds the index, runs the SQL, prints the result rows as a
-JSON array on stdout (byte-identical to the [`POST /query`](./http-api.md)
-response body), and exits `0`.
+The subcommand builds the index, runs the SQL, prints the result rows on
+stdout — a table at a terminal, otherwise a JSON array byte-identical to the
+[`POST /query`](./http-api.md) response body (see
+[Output format](#output-format)) — and exits `0`.
 
 `dirsql query` is a thin adapter over the **same query pipeline the server
 uses**, so behavior is identical to `POST /query` by construction:
@@ -413,7 +416,7 @@ The output does **not** auto-load. Once you've tweaked it, pass it explicitly
 to run against it:
 
 ```bash
-dirsql "SELECT * FROM files" -c ./.dirsql.toml
+dirsql "SELECT * FROM records" -c ./.dirsql.toml
 ```
 
 ### Flags

{dirsql-0.4.60/packages/rust → dirsql-0.4.62}/docs/reference/config.md

@@ -111,6 +111,7 @@ its `embed()` function exactly this way.
 | `command` | yes (non-empty) | The worker command. Argv-split with the same no-shell quoting rules as [command hooks](./hooks.md#argv-not-a-shell); runs in the config file's directory. |
 | `deterministic` | no (default `false`) | When `true`, the function is registered with `SQLITE_DETERMINISTIC`, letting SQLite cache and reuse results for identical arguments within a query. Only set it when the worker really is a pure function of its arguments. |
 | `timeout` | no | Per-**call** time bound: a positive integer is whole seconds (`timeout = 600`), a string is an integer suffixed `s` or `ms` (`"600s"`, `"250ms"`). When absent, the function mechanism's own 30-second default applies. |
+| `batch` | no | A positive integer: the most calls one **batched request** carries. When set, a statement's values are gathered and sent to the worker in bulk (see [Batching](#batching)); the worker must then speak the batched protocol shape as well as the single-call one. When absent, the worker only ever sees single calls. |
 
 ```toml
 [[dirsql.function]]
@@ -173,6 +174,42 @@ request line in, one response line out, per call:
 - **stderr passes through** to `dirsql`'s stderr, so a worker's progress
   bars and download logs reach the terminal.
 
+### Batching
+
+One round trip per row is the wrong shape for a worker whose cost is
+per-request rather than per-value — an embedding model encodes a list of
+texts in little more time than one. A function declaring `batch = N` is sent
+values in bulk instead:
+
+- **Request:** `{"calls": [[<arg>, ...], ...]}` — up to `N` calls, each
+  encoded exactly as a single call's argument list.
+- **Response:** `{"results": [<response>, ...]}` — one single-call response
+  (`{"ok": ...}` with its optional `"meta"`, or `{"err": ...}`) per call, in
+  order. A per-call `{"err": ...}` fails the query the way it would on a
+  single call. A top-level `{"err": "message"}` instead fails every call in
+  the request.
+- The round trip is bounded by the per-call `timeout` **times the number of
+  calls** in the request.
+
+A batching worker must still answer `{"call": [...]}`: `dirsql` gathers a
+statement's values by running it twice. The first run makes one ordinary
+round trip for the function's first value, binds that reply in place of every
+later distinct argument tuple, and queues those tuples into batched requests
+of at most `N`; the second run is served from the replies. A statement that
+never calls a batched function runs once, exactly as before. Values are
+deduplicated along the way, so the [progress line](./cli.md#progress-reporting)
+counts distinct calls, whichever request shape carried them.
+
+```toml
+[[dirsql.function]]
+name          = "embed"
+args          = [1, 2]
+command       = "dirsql-plugin-embeddings worker"
+deterministic = true
+timeout       = "600s"
+batch         = 256
+```
+
 ## `[[table]]`
 
 Each entry maps a glob pattern to a SQL table. A table's columns are exactly

{dirsql-0.4.60 → dirsql-0.4.62}/docs/reference/sdk.md

@@ -54,6 +54,7 @@ DirSQL(
     *,
     tables: list[Table] | None = None,
     ignore: list[str] | None = None,
+    no_ignore: bool = False,
     config: str | list[str] | None = None,
     persist: bool = False,
     persist_path: str | None = None,
@@ -68,6 +69,7 @@ new DirSQL({
     root?: string,
     tables?: TableDef[],
     ignore?: string[],
+    noIgnore?: boolean,
     config?: string | string[],
     persist?: boolean,
     persistPath?: string,
@@ -80,6 +82,7 @@ DirSQL::builder()
     .root(root)                     // optional
     .tables(tables)                 // optional; append one with .table(t)
     .ignore(patterns)               // optional
+    .no_ignore(true)                // optional; default false
     .config(config_toml_path)       // optional; repeatable — call again to
                                     //   merge another config in call order
     .persist(cache_path)            // optional; Some(path), or None for the
@@ -115,6 +118,10 @@ shortcut was removed in #603 — use
 - `tables` — Programmatic [`Table`](#table) definitions.
 - `ignore` — Glob patterns matched against root-relative paths; matched
   files are skipped entirely (scan and watch).
+- `no_ignore` / `noIgnore` — Scan files a `.gitignore` would hide.
+  [Path-tables](./path-tables.md#skip-rules) respect `.gitignore` files by
+  default; the built-in `node_modules`/`.git` skips and any `ignore` patterns
+  still apply. The CLI's [`--no-ignore`](./cli.md#flags).
 - `config` — Path to a [`.dirsql.toml`](./config.md). Its `[[table]]`
   entries are appended after any programmatic `tables`; its `ignore`
   patterns and `[[dirsql.extension]]` entries are appended likewise. The

{dirsql-0.4.60 → dirsql-0.4.62}/packages/python/Cargo.toml

@@ -4,7 +4,7 @@ name = "dirsql-py-ext"
 # pypi/maturin handler can rewrite it via `write-version` before
 # `maturin build`. `pyproject.toml` declares `dynamic = ["version"]`
 # and maturin reads this field. Mirrors `packages/rust/Cargo.toml`.
-version = "0.4.60"
+version = "0.4.62"
 # abi3 note: the `abi3-py310` pyo3 feature (below) builds ONE stable-ABI
 # `cp310-abi3` wheel per platform that loads on every CPython >= 3.10
 # (matching `pyproject.toml`'s `requires-python = ">=3.10"`), instead of

{dirsql-0.4.60/packages/rust → dirsql-0.4.62/packages/python}/docs/getting-started.md

@@ -81,11 +81,15 @@ The first run downloads the package (`npx` asks for confirmation — answer
 `y`; `uvx` prints download progress), then prints the result:
 
 ```
-[{"files":3}]
+files
+-----
+3
+
+1 row
 ```
 
 Three files, three rows. That one command scanned the directory, handed
-SQLite one row per file, ran your SQL, and printed the answer as JSON.
+SQLite one row per file, ran your SQL, and printed the answer.
 
 There is no named table here — you never declared one. `'./'` is a
 [path-table](./reference/path-tables.md): a quoted path written where a table
@@ -94,8 +98,9 @@ in. The path *is* the query.
 
 ## 3. Select some columns
 
-The response is always a JSON array of row objects, so from here on we pipe
-it through `jq` to pretty-print. Ask for two columns instead of a count:
+At a terminal `dirsql` prints a table; when its output is piped, it prints a
+JSON array of row objects instead. From here on we pipe it through `jq` to
+pretty-print. Ask for two columns instead of a count:
 
 ::: code-group
 

{dirsql-0.4.60 → dirsql-0.4.62}/packages/python/docs/howto/write-a-plugin.md

@@ -60,11 +60,12 @@ its `embed()` SQL function),
 and [`ignore`](../reference/config.md#dirsql-keys).
 
 There are **no plugin-specific keys and no plugin-specific restrictions**. The
-config schema is content-only: the index `root` and `--persist` are
-[runner-owned flags](../reference/config.md#dirsql-keys) (`--root`, `--persist
-[PATH]`), decided by whoever runs `dirsql`, never by a config file — so a
-plugin has nothing to say about them. Whatever you can put in your own
-`.dirsql.toml`, a plugin can put in its fragment, and vice-versa.
+config schema is content-only: the index root and persistence are
+[runner-owned](../reference/config.md#dirsql-keys) — the root is the directory
+`dirsql` is run from (or an SDK's explicit `root`), persistence is the
+`--persist [PATH]` flag — decided by whoever runs `dirsql`, never by a config
+file, so a plugin has nothing to say about them. Whatever you can put in your
+own `.dirsql.toml`, a plugin can put in its fragment, and vice-versa.
 
 ## Hook commands
 

{dirsql-0.4.60 → dirsql-0.4.62}/packages/python/docs/plugins.md

@@ -93,9 +93,10 @@ scope.
 ### Vector cache
 
 Computed vectors are cached at `~/.cache/dirsql/embeddings/` (respecting
-`XDG_CACHE_HOME`), keyed on the SHA-256 of the value bytes plus the model
-identifier. Changing either recomputes — switching models never serves stale
-vectors — and re-running a query over unchanged files is cache hits all the
-way. There is no eviction: the directory is **safe to wipe at any time**; the
-only cost is re-embedding. The cache never lives inside a queried tree — the
-worker writes nothing into the directories you query.
+`XDG_CACHE_HOME`): one SQLite database per model identifier, each row keyed
+on the SHA-256 of the value bytes. Changing the value or the model recomputes
+— switching models never serves stale vectors — and re-running a query over
+unchanged files is cache hits all the way, a whole batch answered by one
+query. There is no eviction: the directory is **safe to wipe at any time**;
+the only cost is re-embedding. The cache never lives inside a queried tree —
+the worker writes nothing into the directories you query.

{dirsql-0.4.60/packages/rust → dirsql-0.4.62/packages/python}/docs/reference/cli.md

@@ -1,11 +1,13 @@
 # CLI
 
-Query is the default: `dirsql "<sql>"` runs one query and prints JSON rows.
+Query is the default: `dirsql "<sql>"` runs one query and prints the rows —
+a table at a terminal, a JSON array when piped (see
+[Output format](#output-format)).
 The `dirsql` binary has these modes:
 
 | Invocation | Behavior |
 |---|---|
-| `dirsql "<sql>"` | Run one query over the directory and print the rows as JSON. The default; identical to `dirsql query "<sql>"`. |
+| `dirsql "<sql>"` | Run one query over the directory and print the rows. The default; identical to `dirsql query "<sql>"`. |
 | `dirsql query "<sql>"` | Explicit synonym for the default one-shot query. |
 | `dirsql server` | Start a long-lived HTTP server exposing a SQL view of a directory. See [HTTP API](./http-api.md). |
 | `dirsql init` | Generate a `.dirsql.toml`. |
@@ -53,7 +55,7 @@ pipeline, same flags, same output. See that section for config discovery,
 
 ```bash
 dirsql
-# dirsql 0.2.7 — this directory is a database.
+# dirsql <version> — this directory is a database.
 #
 #   SELECT basename, size FROM './' ORDER BY size DESC LIMIT 5;
 #   SELECT path FROM './**/*.md' WHERE content LIKE '%TODO%';
@@ -331,9 +333,10 @@ is a hard error — `error: the subcommand 'query' cannot be used with
 for the server they follow the subcommand: `dirsql server -c <cfg>`.)
 :::
 
-The subcommand builds the index, runs the SQL, prints the result rows as a
-JSON array on stdout (byte-identical to the [`POST /query`](./http-api.md)
-response body), and exits `0`.
+The subcommand builds the index, runs the SQL, prints the result rows on
+stdout — a table at a terminal, otherwise a JSON array byte-identical to the
+[`POST /query`](./http-api.md) response body (see
+[Output format](#output-format)) — and exits `0`.
 
 `dirsql query` is a thin adapter over the **same query pipeline the server
 uses**, so behavior is identical to `POST /query` by construction:
@@ -413,7 +416,7 @@ The output does **not** auto-load. Once you've tweaked it, pass it explicitly
 to run against it:
 
 ```bash
-dirsql "SELECT * FROM files" -c ./.dirsql.toml
+dirsql "SELECT * FROM records" -c ./.dirsql.toml
 ```
 
 ### Flags

{dirsql-0.4.60 → dirsql-0.4.62/packages/python}/docs/reference/config.md

@@ -111,6 +111,7 @@ its `embed()` function exactly this way.
 | `command` | yes (non-empty) | The worker command. Argv-split with the same no-shell quoting rules as [command hooks](./hooks.md#argv-not-a-shell); runs in the config file's directory. |
 | `deterministic` | no (default `false`) | When `true`, the function is registered with `SQLITE_DETERMINISTIC`, letting SQLite cache and reuse results for identical arguments within a query. Only set it when the worker really is a pure function of its arguments. |
 | `timeout` | no | Per-**call** time bound: a positive integer is whole seconds (`timeout = 600`), a string is an integer suffixed `s` or `ms` (`"600s"`, `"250ms"`). When absent, the function mechanism's own 30-second default applies. |
+| `batch` | no | A positive integer: the most calls one **batched request** carries. When set, a statement's values are gathered and sent to the worker in bulk (see [Batching](#batching)); the worker must then speak the batched protocol shape as well as the single-call one. When absent, the worker only ever sees single calls. |
 
 ```toml
 [[dirsql.function]]
@@ -173,6 +174,42 @@ request line in, one response line out, per call:
 - **stderr passes through** to `dirsql`'s stderr, so a worker's progress
   bars and download logs reach the terminal.
 
+### Batching
+
+One round trip per row is the wrong shape for a worker whose cost is
+per-request rather than per-value — an embedding model encodes a list of
+texts in little more time than one. A function declaring `batch = N` is sent
+values in bulk instead:
+
+- **Request:** `{"calls": [[<arg>, ...], ...]}` — up to `N` calls, each
+  encoded exactly as a single call's argument list.
+- **Response:** `{"results": [<response>, ...]}` — one single-call response
+  (`{"ok": ...}` with its optional `"meta"`, or `{"err": ...}`) per call, in
+  order. A per-call `{"err": ...}` fails the query the way it would on a
+  single call. A top-level `{"err": "message"}` instead fails every call in
+  the request.
+- The round trip is bounded by the per-call `timeout` **times the number of
+  calls** in the request.
+
+A batching worker must still answer `{"call": [...]}`: `dirsql` gathers a
+statement's values by running it twice. The first run makes one ordinary
+round trip for the function's first value, binds that reply in place of every
+later distinct argument tuple, and queues those tuples into batched requests
+of at most `N`; the second run is served from the replies. A statement that
+never calls a batched function runs once, exactly as before. Values are
+deduplicated along the way, so the [progress line](./cli.md#progress-reporting)
+counts distinct calls, whichever request shape carried them.
+
+```toml
+[[dirsql.function]]
+name          = "embed"
+args          = [1, 2]
+command       = "dirsql-plugin-embeddings worker"
+deterministic = true
+timeout       = "600s"
+batch         = 256
+```
+
 ## `[[table]]`
 
 Each entry maps a glob pattern to a SQL table. A table's columns are exactly

{dirsql-0.4.60/packages/rust → dirsql-0.4.62/packages/python}/docs/reference/sdk.md

@@ -54,6 +54,7 @@ DirSQL(
     *,
     tables: list[Table] | None = None,
     ignore: list[str] | None = None,
+    no_ignore: bool = False,
     config: str | list[str] | None = None,
     persist: bool = False,
     persist_path: str | None = None,
@@ -68,6 +69,7 @@ new DirSQL({
     root?: string,
     tables?: TableDef[],
     ignore?: string[],
+    noIgnore?: boolean,
     config?: string | string[],
     persist?: boolean,
     persistPath?: string,
@@ -80,6 +82,7 @@ DirSQL::builder()
     .root(root)                     // optional
     .tables(tables)                 // optional; append one with .table(t)
     .ignore(patterns)               // optional
+    .no_ignore(true)                // optional; default false
     .config(config_toml_path)       // optional; repeatable — call again to
                                     //   merge another config in call order
     .persist(cache_path)            // optional; Some(path), or None for the
@@ -115,6 +118,10 @@ shortcut was removed in #603 — use
 - `tables` — Programmatic [`Table`](#table) definitions.
 - `ignore` — Glob patterns matched against root-relative paths; matched
   files are skipped entirely (scan and watch).
+- `no_ignore` / `noIgnore` — Scan files a `.gitignore` would hide.
+  [Path-tables](./path-tables.md#skip-rules) respect `.gitignore` files by
+  default; the built-in `node_modules`/`.git` skips and any `ignore` patterns
+  still apply. The CLI's [`--no-ignore`](./cli.md#flags).
 - `config` — Path to a [`.dirsql.toml`](./config.md). Its `[[table]]`
   entries are appended after any programmatic `tables`; its `ignore`
   patterns and `[[dirsql.extension]]` entries are appended likewise. The

dirsql-0.4.62/packages/python/e2e-attestations/claude-1196-join-index.json

@@ -0,0 +1,7 @@
+{
+  "command": "just test-e2e",
+  "ran_at": 1790959572,
+  "exit_code": 0,
+  "commit": "16f02f05e5f6ca5fc06ad5ce716fae9d1ce78bc5",
+  "branch": "claude/1196-join-index"
+}

dirsql-0.4.62/packages/python/e2e-attestations/claude-1201-single-walk.json

@@ -0,0 +1,7 @@
+{
+  "command": "just test-e2e",
+  "ran_at": 1790945578,
+  "exit_code": 0,
+  "commit": "c74aacb34e2aa97f26338176180e7e063f83465b",
+  "branch": "claude/1201-single-walk"
+}

dirsql-0.4.62/packages/python/e2e-attestations/claude-1204-embed-batch.json

@@ -0,0 +1,7 @@
+{
+  "command": "just test-e2e",
+  "ran_at": 1790942055,
+  "exit_code": 0,
+  "commit": "b9f0529e785dd54fa49496fb3fa48bbcdb14764d",
+  "branch": "claude/1204-embed-batch"
+}

dirsql-0.4.62/packages/python/e2e-attestations/claude-1226-stale-docs.json

@@ -0,0 +1,7 @@
+{
+  "command": "just test-e2e",
+  "ran_at": 1790960011,
+  "exit_code": 0,
+  "commit": "b36c8055c086002c81314daa2d7e34cded58b561",
+  "branch": "claude/1226-stale-docs"
+}

{dirsql-0.4.60 → dirsql-0.4.62}/packages/rust/Cargo.toml

@@ -6,7 +6,7 @@ description = "Ephemeral SQL index over a local directory"
 # version stays for the binding crates (publish = false). The literal
 # intentionally lags the published version: putitoutthere rewrites it to
 # the planned release version at build time and never commits it back.
-version = "0.4.60"
+version = "0.4.62"
 edition.workspace = true
 # Literal `license` (not `license.workspace = true`) because
 # putitoutthere's preflight check reads `[package].license` directly
@@ -69,7 +69,7 @@ globset = "0.4"
 # library consumer never pulls it.
 hex = { version = "0.4", optional = true }
 # Hierarchical `.gitignore` matching for path-table scans (the fd/ripgrep
-# semantics), without adopting its walker: the scan keeps `walkdir`.
+# semantics), without adopting its walker: the scan has its own.
 ignore = "0.4"
 indicatif = "0.18.6"
 notify = "7"
@@ -87,7 +87,6 @@ tokio.workspace = true
 tokio-stream = { version = "0.1", features = ["sync"], optional = true }
 toml = "0.8"
 typed-path = "0.12"
-walkdir = "2"
 
 [lints.rust]
 # `deny`, not `forbid`: rusqlite's API imposes five unavoidable `unsafe`

{dirsql-0.4.60/packages/python → dirsql-0.4.62/packages/rust}/docs/getting-started.md

@@ -81,11 +81,15 @@ The first run downloads the package (`npx` asks for confirmation — answer
 `y`; `uvx` prints download progress), then prints the result:
 
 ```
-[{"files":3}]
+files
+-----
+3
+
+1 row
 ```
 
 Three files, three rows. That one command scanned the directory, handed
-SQLite one row per file, ran your SQL, and printed the answer as JSON.
+SQLite one row per file, ran your SQL, and printed the answer.
 
 There is no named table here — you never declared one. `'./'` is a
 [path-table](./reference/path-tables.md): a quoted path written where a table
@@ -94,8 +98,9 @@ in. The path *is* the query.
 
 ## 3. Select some columns
 
-The response is always a JSON array of row objects, so from here on we pipe
-it through `jq` to pretty-print. Ask for two columns instead of a count:
+At a terminal `dirsql` prints a table; when its output is piped, it prints a
+JSON array of row objects instead. From here on we pipe it through `jq` to
+pretty-print. Ask for two columns instead of a count:
 
 ::: code-group
 

{dirsql-0.4.60 → dirsql-0.4.62/packages/rust}/docs/howto/write-a-plugin.md

@@ -60,11 +60,12 @@ its `embed()` SQL function),
 and [`ignore`](../reference/config.md#dirsql-keys).
 
 There are **no plugin-specific keys and no plugin-specific restrictions**. The
-config schema is content-only: the index `root` and `--persist` are
-[runner-owned flags](../reference/config.md#dirsql-keys) (`--root`, `--persist
-[PATH]`), decided by whoever runs `dirsql`, never by a config file — so a
-plugin has nothing to say about them. Whatever you can put in your own
-`.dirsql.toml`, a plugin can put in its fragment, and vice-versa.
+config schema is content-only: the index root and persistence are
+[runner-owned](../reference/config.md#dirsql-keys) — the root is the directory
+`dirsql` is run from (or an SDK's explicit `root`), persistence is the
+`--persist [PATH]` flag — decided by whoever runs `dirsql`, never by a config
+file, so a plugin has nothing to say about them. Whatever you can put in your
+own `.dirsql.toml`, a plugin can put in its fragment, and vice-versa.
 
 ## Hook commands
 

{dirsql-0.4.60 → dirsql-0.4.62/packages/rust}/docs/plugins.md

@@ -93,9 +93,10 @@ scope.
 ### Vector cache
 
 Computed vectors are cached at `~/.cache/dirsql/embeddings/` (respecting
-`XDG_CACHE_HOME`), keyed on the SHA-256 of the value bytes plus the model
-identifier. Changing either recomputes — switching models never serves stale
-vectors — and re-running a query over unchanged files is cache hits all the
-way. There is no eviction: the directory is **safe to wipe at any time**; the
-only cost is re-embedding. The cache never lives inside a queried tree — the
-worker writes nothing into the directories you query.
+`XDG_CACHE_HOME`): one SQLite database per model identifier, each row keyed
+on the SHA-256 of the value bytes. Changing the value or the model recomputes
+— switching models never serves stale vectors — and re-running a query over
+unchanged files is cache hits all the way, a whole batch answered by one
+query. There is no eviction: the directory is **safe to wipe at any time**;
+the only cost is re-embedding. The cache never lives inside a queried tree —
+the worker writes nothing into the directories you query.

{dirsql-0.4.60/packages/python → dirsql-0.4.62/packages/rust}/docs/reference/cli.md

@@ -1,11 +1,13 @@
 # CLI
 
-Query is the default: `dirsql "<sql>"` runs one query and prints JSON rows.
+Query is the default: `dirsql "<sql>"` runs one query and prints the rows —
+a table at a terminal, a JSON array when piped (see
+[Output format](#output-format)).
 The `dirsql` binary has these modes:
 
 | Invocation | Behavior |
 |---|---|
-| `dirsql "<sql>"` | Run one query over the directory and print the rows as JSON. The default; identical to `dirsql query "<sql>"`. |
+| `dirsql "<sql>"` | Run one query over the directory and print the rows. The default; identical to `dirsql query "<sql>"`. |
 | `dirsql query "<sql>"` | Explicit synonym for the default one-shot query. |
 | `dirsql server` | Start a long-lived HTTP server exposing a SQL view of a directory. See [HTTP API](./http-api.md). |
 | `dirsql init` | Generate a `.dirsql.toml`. |
@@ -53,7 +55,7 @@ pipeline, same flags, same output. See that section for config discovery,
 
 ```bash
 dirsql
-# dirsql 0.2.7 — this directory is a database.
+# dirsql <version> — this directory is a database.
 #
 #   SELECT basename, size FROM './' ORDER BY size DESC LIMIT 5;
 #   SELECT path FROM './**/*.md' WHERE content LIKE '%TODO%';
@@ -331,9 +333,10 @@ is a hard error — `error: the subcommand 'query' cannot be used with
 for the server they follow the subcommand: `dirsql server -c <cfg>`.)
 :::
 
-The subcommand builds the index, runs the SQL, prints the result rows as a
-JSON array on stdout (byte-identical to the [`POST /query`](./http-api.md)
-response body), and exits `0`.
+The subcommand builds the index, runs the SQL, prints the result rows on
+stdout — a table at a terminal, otherwise a JSON array byte-identical to the
+[`POST /query`](./http-api.md) response body (see
+[Output format](#output-format)) — and exits `0`.
 
 `dirsql query` is a thin adapter over the **same query pipeline the server
 uses**, so behavior is identical to `POST /query` by construction:
@@ -413,7 +416,7 @@ The output does **not** auto-load. Once you've tweaked it, pass it explicitly
 to run against it:
 
 ```bash
-dirsql "SELECT * FROM files" -c ./.dirsql.toml
+dirsql "SELECT * FROM records" -c ./.dirsql.toml
 ```
 
 ### Flags