Repository navigation
v0.8.1 — Cypher WITH fixes
Four pre-existing defects in WITH, all found while documenting a limitation for the 0.8.0 pattern-predicate work. Each fix let queries be written that had not parsed before, which is how the next one surfaced.
A WITH can filter on the aliases it projects
MATCH (n:P) WITH n, n.age AS age WHERE age > 25 RETURN n.name
-- was: Variable 'age' not found in contextThe non-aggregating path filtered the input rows, so the clause's own aliases did not exist yet — while the aggregating path already filtered after grouping, which is why WITH n, count(m) AS c WHERE c > 1 worked and the simple case did not.
The predicate now sees the projected names plus the bindings that came in. Keeping the latter is deliberate: standard Cypher drops them from scope, but filtering on an unprojected variable already worked here and tightening it would break queries for no gain.
WITH accepts the same expressions RETURN does
RETURN n.age * 2 AS doubled -- fine
WITH n.age * 2 AS doubled -- was a syntax errorArithmetic, comparisons and function calls had to be wrapped in parentheses to survive a WITH.
WITH * and RETURN *
MATCH (p)-[r:KNOWS]->(other)
WITH *
WHERE r.weight > 5
RETURN *Neither clause accepted *, so carrying a multi-variable match through a WITH meant naming every variable. It combines with named items — WITH *, p.age * 2 AS doubled.
Two semantics worth knowing: * expands to bound variables, not to columns an earlier stage produced (otherwise it would accumulate at every stage); and with an aggregate it contributes every variable to the implicit GROUP BY, so WITH *, count(m) groups per (n, m) rather than per n.
ORDER BY / SKIP / LIMIT after a trailing RETURN
MATCH (n:P) WITH n.age AS d RETURN d AS r ORDER BY r -- came back unsortedThe WITH parser kept one slot per modifier and accepted them in any order, so anything written after the RETURN was stored as the WITH's own and applied before the final projection. With one on each clause, neither took effect.
They now attach to whichever clause they follow:
MATCH (p:Person)
WITH p, p.age AS age
ORDER BY age DESC LIMIT 10 -- top ten by age
RETURN p.name AS name
ORDER BY name -- those ten, alphabeticalSorting keys resolve against the RETURN's output and the rows that fed it, since ORDER BY may name either a column it introduced or a name the WITH carried without projecting.
Scope
Patch rather than minor: no new API surface, and nothing that already worked behaves differently. Each of these was a syntax error or a silently ignored clause before.
Full changelog: v0.8.0...v0.8.1