Eng 1062 optimize all relations

[maparent]

Use a pseudo-relation for a query for all relations. Rework the algorithm for grouping results, which means adding some selections.

https://www.loom.com/share/ced1e4cf67ec4acdb97db690431ee9a0

[linear]

ENG-1062 Roam query optimization: Single query for all relations

[supabase]

This pull request has been ignored for the connected project zytfjzqyijgagqxrzbmz because there are no changes detected in packages/database/supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
discourse-graph	Skipped		Jun 24, 2026 1:24pm

[maparent]

Detecting the "all relations" case

[maparent]

Create a new case for all relations

[maparent]

Since we look at all relations at once, we have to re-group by relation type here.

[maparent]

The results are the same between both versions, so I think I got it right, but I'll admit to a bit of guesswork here.

[devin-ai-integration]

Devin Review found 4 potential issues.

[devin-ai-integration]

🔴 target set to UID instead of node type, producing undefined in results

In the reified relations regrouping block, target is set to targetUid (a block UID). This value is later used at line 323 as nodeTextByType[r.relation.target] to look up the display text, but nodeTextByType is keyed by node type strings (e.g., "QUE", "CLM", "*"), not UIDs. This will always resolve to undefined, breaking the "group by target" feature in DiscourseContext.tsx:46 which maps results via res.target. In the non-reified path, target is correctly set to the node type via buildQueryConfig at line 124 (isComplement ? r.source : r.destination). The reified path should similarly use the relation's source or destination type.

Suggested change

	target: targetUid,
	target: ruid.endsWith("-true") ? relation.r.source : relation.r.destination,

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[mdroidian]

@maparent Devin flagged a few issues here. Could you take a look and address them, then re-tag me once they’re resolved?

[maparent]

@mdroidian resolved the issues.

[mdroidian]

I like the high-level goal here: in reified-relations mode, discourse context should not have to run one query per relation type. A single “all relations touching this node” query, followed by regrouping, is the right direction.

I don’t think we should merge the current implementation shape as-is, though. It feels too brittle/indirect for a core discourse context path.

The main issue is that hasSchema and effectiveSource are being added as synthetic predefined selections so we can carry internal relation metadata out of the query. Predefined selections are part of the Query Builder/user-facing selection layer; these values are not real user selections, they are internal Datalog variables needed by this one caller. The placeholder mapper implementations returning "?relSchema" / "?relSource" are a signal that this is not really a selection abstraction. That also forces relSchema and relSource to be preserved globally in the relation translator.

There are also some correctness issues in the regrouping:

• The complement handling looks backwards. For keys ending in -true, the code sets isComplement: true but uses relation.r.label for label/text; for -false, it uses relation.r.complement. Based on how uniqueRelations is built, and based on the existing text = isComplement ? r.complement : r.label logic, those should be flipped.
• id becomes the grouped key like ${relationUid}-${direction} instead of the underlying relation schema id. That changes the meaning of the result id from relation id to implementation grouping key. Direction already has isComplement, so the grouped key should not escape as id.
• onResult behavior changed. Previously executeQueries received onResult and could call it per relation query as each query completed; now results are buffered, empty groups are filtered, and callbacks fire at the end. That may be intentional, but it is a behavior change outside just the reified-relations optimization and should be tested/called out.

There are a few ways we could take this. I’ll elaborate on two:

• Option 1: add a findVariables internal API.
• Option 2: special-case the discourse context query outside of the Query Builder translator.

I put together an example of Option 1 here: #1160

That keeps the one-query approach and still reuses the existing Has Any Relation To translator, but it adds an internal findVariables API to fireQuery instead of adding fake predefined selections. So discourse context can explicitly ask for the scoped relSchema / relSource variables it needs, without exposing them as Query Builder selections.

Option 2 would be to special-case discourse context directly: since the discourse context overlay is the hot path here, we could build a direct reified-relation Datalog query for this flow and map the stored relation metadata into groups ourselves. That would be less reusable with Query Builder, but it may be the clearest implementation if this optimization is specifically for discourse context.

My recommendation is that we should not keep the fake predefined-selection approach. I’d be comfortable with either Option 1 from the example PR, or Option 2 as a dedicated discourse-context query path, but the current version is coupling too many layers in a brittle way.

[mdroidian]

if you add the id outside r as well, it'll match the type RelationWithComplement cleanly

[mdroidian]

reuse ANY_RELATION_REGEX.source