SOP-DATALOG-COOKBOOK-1.0Rev. v1.0··2026-06-23

Datalog Patterns Cookbook··5 recipes for mium power users

Copy-ready queries, honest gotchas

PROCEDURE

1
Check property discipline — make sure frist::, status::, owner::, tags:: are maintained consistently in the target blocks before a recipe runs.
TOOLS
mium outliner
DURATION10 min
☐Checkpoint: A sample of 20 blocks carries the expected properties.
2
Normalise the date format — use a re-pattern pre-filter to expose mixed formats (15.07.2026, Jul 15) and unify them to YYYY-MM-DD.
MATERIALS
Date normalisation note
DURATION15 min
☐Checkpoint: The re-pattern filter finds no deviating deadline values any more.
3
Choose and parameterise a recipe — adjust the Q window, tag namespace and limit to your own vault, copy the query text from the cookbook.
TOOLS
Datalog query
DURATION10 min
☐Checkpoint: The query runs without syntax errors and returns a plausible, non-empty set.
4
Check the result against the gotcha — for each recipe, cross-check the known weak spot (edge count, history availability, namespace existence).
DURATION10 min
☐Checkpoint: The recipe's known source of error is ruled out or documented.
5
Decouple expensive runs — schedule the orphan detector (not-join) on large vaults as an overnight cron job rather than running it interactively.
TOOLS
Cron job (mium)
MATERIALS
Scheduled query
DURATION10 min
☐Checkpoint: The not-join run is scheduled, not interactive; or a has-backlinks? property is maintained.
6
Anchor the view as a bookmark — save the checked query as a recurring view and share it across the team, rather than rewriting it each time.
TOOLS
Query bookmark
DURATION5 min
☐Checkpoint: The query is saved as a shared view and discoverable across the team.

BACKGROUND

This cookbook is aimed at mium power users and developer profiles who have already brushed against [[advanced-query-datalog]] and are after concrete, copy-ready examples. Five recipes, each self-contained — anyone who only needs the orphan detector jumps straight to recipe 5. Datalog itself is a logic programming language from the 1970s; Rich Hickey rediscovered it with Datomic (Cognitect, since 2012) for practical everyday database work. mium uses a Datalog dialect to query its own block index.

Recipes

The five recipes are independent of one another. Cherry-pick what you need, or read linearly — both orders work. Every recipe has: a problem, a query, optionally a gotcha callout.

Recipe 1··Open tasks with a deadline in the current quarter

The standard sprint question: which tasks are open and have to be delivered by the end of the quarter? The query filters on `frist::` within the Q window and `status:: offen`, and returns the owner.

[:find ?block ?frist ?owner
 :where [?block :frist ?frist]
        [?block :status "offen"]
        [(>= ?frist "2026-04-01")]
        [(<= ?frist "2026-06-30")]
        [?block :owner ?owner]]

Recipe 2··Top 10 backlink hubs

Which blocks are referenced most often? The top 10 by incoming `:links-to` edges are the central nodes of your vault — often terms, people, projects.

[:find (count ?backlink) ?target
 :where [?backlink :links-to ?target]
 :order-by [(count ?backlink) :desc]
 :limit 10]

Recipe 3··Audit trail of a block

Who changed what, and when, on a block? The query reads the transaction history in reverse for a given block ID and returns `tx`, `attr`, `value`, and the `added` flag.

[:find ?tx ?attr ?value ?added
 :where [?block :db/id "<((uuid))>"]
        [?tx :tx/affected-block ?block]
        [?tx :tx/attr ?attr]
        [?tx :tx/value ?value]
        [?tx :tx/added ?added]]

Recipe 4··Cross-vault tag aggregation

How often does each client tag occur across all vaults? The query groups on `tags::` with the namespace prefix `#kunde-` and returns a sorted frequency list.

[:find (count ?block) ?tag
 :where [?block :tags ?tag]
        [(re-pattern "^#kunde-") ?tag]
 :group-by ?tag
 :order-by [(count ?block) :desc]]

Recipe 5··Orphan note detector

Which notes have no incoming backlinks and are not archived? These orphans are the dead ends of the vault — candidates for tidying, linking or archiving.

[:find ?block ?title
 :where [?block :title ?title]
        [?block :archiv? false]
        (not-join [?block]
          [?other :links-to ?block])]

When these recipes do NOT fit

Datalog queries are not a universal instrument. Three situations in which these recipes do not hold:

Full-text search in the block content — Datalog filters on properties and edges, not on prose. For “find every block that contains `Auftragsbestätigung` in its text”, the mium full-text index is the right instrument, not a Datalog query.
Very unstructured vaults with no property discipline — all five recipes assume that `frist::`, `status::`, `owner::`, `tags::` are maintained consistently. In a vault where 80% of blocks carry no properties, the queries return empty sets, not insight. Property discipline is groundwork, not a side effect.
Ad-hoc explorations with an unclear question — Datalog rewards precise questions. Anyone who just wants to “have a look at what is in the vault” gets there faster with the graph view or backlink browsing than with a query that still has to be designed.

An honest question

Which of the five recipes fit for you, and which ran into the void? If you put one of them into production: what did you parameterise differently — shifted the Q window, changed the tag namespace, raised the limit? And if none fit: where did we miss the gap? Cookbook recipes live by rubbing up against real vaults — feedback on which recipe #6 is missing here is welcome. Further on in this wave: [[advanced-query-datalog]] for the language fundamentals, [[simple-query]] for the gentler entry without Datalog syntax.