Skip to content
Embabel Worlds

3.11 A bridge reachable only through another virtual node (staged re-planning)

MATCH (o:HubSpotOwner)-[:OWNS_CONTACT]->(c:HubSpotContact)<-[:HAS_HUBSPOT_CONTACT]-(p:Person)-[:HAS_GITHUB]->(g:GitHubIdentity)-[:RAISED]->(i:GitHubIssue)
WHERE o.email = 'me@example.com'
RETURN p.name, i.title

Means: “For the contacts I own in HubSpot, which of those people are on GitHub, and what issues did they raise?” The GitHub anchor p is reachable only through a virtual node (c), which doesn’t exist until HubSpot is fetched.

How it executes — in waves:

  • Wave 1. Only o is bound (by the literal email). Materialize c (the owned contacts) from o. Now c is real for this transaction.
  • Wave 2. With c real, the closure extends through it to p (the canonical Person behind each contact) — p is now bound. Resolve the HAS_GITHUB bridge for those people → materialize g.
  • Wave 3. With g real, materialize i (their issues).
  • Run / roll back over the fully-assembled graph.

The engine re-plans after each wave, treating everything materialized so far as real, until no new virtual node becomes reachable (a fixpoint, bounded by a stage cap). You write one query; the engine discovers the dependency order.