Matches a relationship with direction, type, and optional variable-length path.
-[<variable>:<TYPE> *<min>..<max> {<prop>: <val>}]->
<-[...]- (incoming)
-[...]- (undirected)## Overview The relationship pattern describes how two nodes are connected in a graph pattern. It specifies the direction of traversal, the relationship type(s), optional variable binding, inline property constraints, and variable-length path ranges. Relationship patterns are placed between node patterns to form complete graph patterns used in MATCH, CREATE, MERGE, and other clauses. In DeltaForge, each relationship corresponds to a row in an edge Delta table registered in the graph definition. The source and target columns in the edge table define the direction, and the relationship type column determines the type filter. Variable-length paths are expanded by the CSR traversal engine using bounded BFS or DFS. ## Behavior - Direction is determined by the arrow syntax: `->` for outgoing, `<-` for incoming, and `-` (no arrow) for undirected traversal. Undirected traversal matches edges in both directions. - Multiple relationship types separated by `|` are treated as OR: `-[r:colleague|teammate]->` matches edges of either type. - Variable-length paths (`*min..max`) produce one result row per distinct path. The min defaults to 1 and the max, if omitted, is internally capped by the engine's maximum traversal depth. - Inline property constraints on relationships are equality filters applied during edge iteration, reducing intermediate result size. - Binding a variable to the relationship (`-[r:type]->`) enables property access (r.weight), type inspection (type(r)), and use in SET/REMOVE/DELETE. ## Limitations - Variable-length paths do not support per-hop property filtering. The property constraint on a variable-length pattern applies to the entire path aggregation, not to individual hops. - Unbounded variable-length paths (`-[*]->`) are capped at an internal maximum hop limit. Specify explicit bounds for predictable behavior. - Relationship patterns in CREATE must be single-hop; variable-length patterns cannot be used in write operations.
| Name | Type | Description |
|---|---|---|
variable | Binds the matched relationship to a named variable for reference in subsequent clauses. Required when accessing relationship properties in WHERE, RETURN, or SET. | |
rel_types | Specifies one or more relationship types to filter by. Multiple types are treated as a disjunction (the relationship must match any one of the specified types). Types correspond to the relationship type column in the edge Delta table. | |
direction | Specifies traversal direction. Valid values: Outgoing (->), Incoming (<-), or Both (-). Default is Both (undirected) when no arrow is specified. | |
length | Enables variable-length path matching. Specifies a hop range as *min..max. Omitting min defaults to 1; omitting max allows unbounded traversal (subject to engine limits). A bare * is equivalent to *1.. (one or more hops). | |
properties | Specifies inline property constraints as key-value pairs on the relationship. Each entry is an equality predicate against edge columns in the backing Delta table. |
-- Outgoing relationship with a specific type
-[:mentor]->-- Multiple relationship types (OR semantics)
-[r:colleague|teammate]->-- Variable-length path: 1 to 5 hops
-[*1..5]->-- Incoming relationship with a bound variable
<-[r:reports_to]--- Relationship with property constraint
-[r:referral {status: 'active'}]->-- Used in a full query: mentorship chains with edge properties
USE my_zone.my_schema.my_graph
MATCH (a)-[r:mentor]->(b)
RETURN a.name AS mentor, b.name AS mentee, r.weight AS bond_strength
ORDER BY r.weight DESC;