Skip to content
Embabel Worlds

3.3 A literal-seeded anchor — fetch anyone's data through your credentials

MATCH (g:GitHubIdentity {login:'octocat'})-[:RAISED]->(i:GitHubIssue)
RETURN i.title

Means: “What has octocat raised?” — octocat is not someone in your graph; you just named a GitHub login directly.

How it executes:

  • Probe — try to bind g as a real node. There is no GitHubIdentity {login:'octocat'} in the graph, so the engine seeds a transient anchor from the literal: a virtual GitHubIdentity whose login is octocat.
  • Fetch / materialize / run — exactly as §3.2 from the resolved-identity step onward, keyed on octocat, fetched with your GitHub credentials.
  • Roll back — the seeded identity and its issues all vanish.

Declared: nothing extra — the same GitHubIssue join. Seeding falls out of the rule that a pinned literal (inline {login:'…'} or WHERE g.login = '…') can stand in for a missing real anchor.

Why this matters. It turns the connecting user’s API access into a query surface over the whole external system, not just their own row. “Issues octocat raised”, “contacts at acme.com”, “the movie with imdb id tt0133093” are all literal-seeded fetches. Multiple seeded joins compose and intersect: MATCH (me)-[:RAISED]->(i)<-[:ASSIGNED]-(:GitHubIdentity {login:'octocat'}) materializes both sides and keeps only issues you raised that octocat is assigned.