-
Notifications
You must be signed in to change notification settings - Fork 0
index and search
aniongithub edited this page May 19, 2026
·
1 revision
The index lives in .mind-map.db inside the wiki root. SQLite, WAL mode, recursive_triggers = ON.
CREATE TABLE pages (
path TEXT PRIMARY KEY,
title TEXT NOT NULL DEFAULT '',
body TEXT NOT NULL DEFAULT '',
meta TEXT NOT NULL DEFAULT '{}',
modified TEXT NOT NULL DEFAULT '' -- RFC3339Nano
);
CREATE TABLE links (
source TEXT NOT NULL,
target TEXT NOT NULL,
PRIMARY KEY (source, target)
);
CREATE TABLE page_locks (
path TEXT PRIMARY KEY,
holder TEXT NOT NULL,
acquired TEXT NOT NULL
);
CREATE VIRTUAL TABLE pages_fts USING fts5(
path, title, body,
content='pages',
content_rowid='rowid'
);Triggers on pages (INSERT / DELETE / UPDATE) keep pages_fts in sync. recursive_triggers = ON is critical: without it, INSERT OR REPLACE would silently leak orphan docids into the FTS index.
| Table | Role | Driven by |
|---|---|---|
pages |
Canonical content | Every write |
links |
Forward/back edge graph | concepts/wikilinks extracted during indexing |
pages_fts |
concepts/search | Triggers off pages
|
page_locks |
Concurrency | architecture/wiki-engine |
The link table is what powers concepts/backlinks and the architecture/web-ui. The FTS5 virtual table is what powers the search box.
Wiki.Reindex(ctx) walks the wiki root, compares each file's mtime against the row in pages, and only re-parses the ones that have changed. Files that no longer exist on disk are removed from the index. Cheap to call — sub-second for thousands of pages.
- architecture/wiki-engine — how writes flow into this schema
- concepts/search — query syntax
- design/lightweight — why SQLite (and not a separate index daemon)