element_id
Generic Description
Inspects graph identity, labels, relationship type, direction, or endpoint information. It is documented separately because graph identity and topology helpers affect how rows refer back to stored nodes, relationships, and labels.
Simple example:
MATCH (a)-[r]->(b) RETURN id(a), labels(a), type(r), startNode(r), endNode(r)
Consumer-Level Explanation
Use it when graph structure itself is part of the answer rather than only a path to property values. Prefer this function when the returned graph metadata is part of the answer or a later join key, not just debug output.
More Detailed Explanation
element_id should be understood by the value shape it expects and the row shape it returns. It composes with MATCH, WHERE, WITH, RETURN, and procedure output, so planner-facing documentation should describe both the immediate value transformation and why it belongs in the database query.
Advanced Example
This example uses element_id inside a named row pipeline so the value shape is clear to both the planner and reviewers.
MATCH (u:User)-[e:VIEWED]->(d:Document)
TIME e.ts BETWEEN datetime('2025-01-01T00:00:00Z') AND datetime('2025-02-01T00:00:00Z')
WITH u, e, d,
unpivot(properties(d.metadata)) AS metadata_rows,
date_trunc('day', e.ts) AS day_bucket,
element_id(d) AS focused_value
RETURN u.user_id, d.title, day_bucket, metadata_rows, focused_value
LIMIT 10
Real Use Cases
- keeping value shaping visible to the planner and reviewers
- combining graph structure with document-style payload handling
- returning named, typed fields that downstream tooling can reason about
Real Limitations And Tradeoffs
- the function does not repair incorrectly modeled input values
- nearby aliases may be clearer if they express the business intent more directly
- broad use inside hot filters should be reviewed for cost and index interaction