Skip to content

index and search

aniongithub edited this page May 19, 2026 · 1 revision

title: Index and search type: component

Index and search

The index lives in .mind-map.db inside the wiki root. SQLite, WAL mode, recursive_triggers = ON.

Schema

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.

Three tables, three roles

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.

Re-indexing

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.

See also

Clone this wiki locally