Relations that route — joins, FK placement, salting

Relations that route — joins, FK placement, salting #

A fact collection can now behave like one. Declare the relationship in the schema and the engine takes over:

"org_id": {
  "type": "keyword",
  "immutable": true,
  "references": {"collection": "orgs"},
  "routing": true,
  "ref": true
}

• Join queries are live — a semi-join over the wire: the inner query runs on the referenced collection, its matching keys become a membership filter on the outer side, and joins through a declared references field resolve without a second fan-out.
• Writes place by the foreign key’s value — hash(org_id) picks the home partition, not the document key, so an org’s facts colocate. Key-addressed operations take ?routing=<value> ( fetch, update, delete).
• Salting splits the hot org — when one routing value dominates, the _salting API spreads its writes across a partition SET (deterministic per key, round-robin for auto-IDs), with a terms feed that flags candidates against your threshold. Assignments are never auto-applied and searches stay oblivious — salting changes placement, never visibility.

One declaration, three consequences:

Lesson 8 — Joins

Lesson 8 — Joins #

Traversal (Lesson 5) walks edges inside ONE collection. A join spans TWO: it answers questions a single collection cannot — orders whose customer is gold-tier, where the tier lives in a different collection.

Joins need a running node (the gateway orchestrates the two sides, which is why the wasm playground does not host them), so this lesson is curl against your Lesson 1 node — no live widget. Like traverse, join stays DSL-side outside the SQL M1 subset.