Relational queries on INFINI Pizza

Nested query

Mon, 01 Jan 0001 00:00:00 +0000

Nested query #

Matches parent documents whose nested sub-documents — objects mapped with "nested": true — satisfy a query within one element at a time.

The cross-element problem #

A flattened index correlates across array elements, not within them: variants.color = blue AND variants.size = L matches a document as soon as some element is blue and some element is L — not necessarily the same one. The teaching dataset’s products makes the difference visible (each element pairs blue with L, never with M):

Join query

Mon, 01 Jan 0001 00:00:00 +0000

Join query #

Status: not yet functional. The join query parses and its wire format is stable, but execution currently returns no matches — the rewrite_joins machinery exists in the engine yet no production caller resolves the inner index. Do not rely on it; use traverse (graph edges) or application-side lookups until a release note declares joins operational. There is no live playground demo for this reason.

Matches documents in the current index whose target_field values intersect the join_on values of documents matching a query on another (inner) index — a semi-join. Use "_key" as the field name to join on document primary keys.

Traverse query

Mon, 01 Jan 0001 00:00:00 +0000

Traverse query #

A bounded graph traversal over a relation-typed edge field: starting from seed documents, walk the edges up to max_depth hops and emit every reached node as a hit.

Scores encode distance — 1.0 / (1.0 + depth) — so seeds outrank 1-hop neighbors, which outrank 2-hop neighbors, and the standard top-K collector orders the results.

Examples #

POST /my-collection/_search
{
 "query": {
 "traverse": {
 "field": "related_to",
 "seed": {
 "query": { "term": { "field": "topic", "value": "search-engines" } }
 },
 "max_depth": 2,
 "direction": "outgoing"
 }
 }
}

Seeds by document _key (the string ids you index with):

Graph projection block

Mon, 01 Jan 0001 00:00:00 +0000

Graph projection block #

Add a graph block to any search request and the response carries a graph — nodes and edges — built from the hit set, alongside the normal hits. Where the traverse query searches by walking edges, the graph block renders: it takes the documents a query already found and projects them into a node/edge structure a UI (or a GraphRAG pipeline) can consume directly.

Live over the articles teaching dataset (44 documents with a related_to relation field) — a term query picks the seeds, the graph block renders everything they reach: