Datalog Patterns Cookbook··5 recipes for mium power users
Copy-ready queries, honest gotchas
- You read and parameterise the five cookbook queries for your own vault. ·· Success criterion: You adjust the Q window, tag namespace and limit correctly in three recipes without breaking the syntax.
- You name, per recipe, the honest point where it does not hold, and its prerequisite. ·· Success criterion: You match five gotchas (date format, edge count, history, namespace, not-join cost) to their recipe without error.
- You decide when a Datalog query is the wrong means and another route wins. ·· Success criterion: You recognise in five cases whether Datalog, the full-text index or the graph view gives the right answer.
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.
- Take recipe 1 and adjust it to your current quarter and your property names. Check up front with a re-pattern filter whether your deadline values are even maintained consistently as YYYY-MM-DD — and note how many blocks fall through the net.⏱ 15 min
💡 Run only the two date comparisons first, without the status filter. If the result stays empty even though you have open deadlines, it is almost always the date format, not the logic.
Model answer: The Q window is set to your own quarter boundaries (say 2026-07-01 to 2026-09-30), the property names adjusted to your own convention. The re-pattern pre-filter exposes the mixed formats — typically a few blocks turn up with 15.07.2026 or Jul 15 that have to be normalised to YYYY-MM-DD before the query. Only then does the deadline filter hold reliably. - Run recipe 5 (orphan detector) over your vault once and count the hits. Decide per orphan whether it should be linked, archived or deleted — and consider whether the run is bearable interactively for you or belongs in a cron job.⏱ 20 min
💡 If the query noticeably hangs interactively, your vault is large enough for the not-join cost. Then maintain a has-backlinks? property instead and filter on it directly.
Model answer: The orphan list is the most honest mirror of the vault: genuine dead ends get linked or archived, deliberate one-off notes (inbox, journal) stay. On small vaults the recipe runs interactively; from around fifty thousand blocks it moves into an overnight cron run, or is replaced by a maintained has-backlinks? property that avoids the expensive not-join.
Why does recipe 1 (deadline filter) return an empty set rather than an error on mixed date formats?
What does recipe 2 (backlink hubs) count by default that you would have to filter out deliberately?
When is a Datalog query the wrong means?
Why does the orphan detector (recipe 5) belong in an overnight cron run on large vaults?