Multi-Statement Scripts
Generic Description
A Nexyron Cypher script is one query text containing multiple Cypher statements separated by semicolons. The runtime parses the text once as a script, then executes each statement from left to right on the same session. The final statement result is returned to the caller.
CREATE (u:User {uid: 'u1', name: 'Ada'});
CREATE (o:Order {order_id: 'ord-1', user_uid: 'u1'});
MATCH (u:User {uid: 'u1'}) RETURN u.name AS name
Consumer-Level Explanation
Use a script when a workflow is naturally staged: create data then inspect it, compute a global value then compare normal rows against it, run a narrow lookup then use that result in a second lookup, or perform a few ordered maintenance commands in one submitted query text.
Scripts are not a replacement for normal Cypher pipelines. If one statement with WITH, CALL { ... }, UNWIND, or a procedure call is clearer and cheaper, prefer one statement. A script is useful when the stages are easier to reason about as separate statements or when a write must complete before a later read.
Conceptual Explanation
Each statement is still a normal Nexyron Cypher statement. Semicolons separate statements; they are not part of a clause. Execution is sequential and the session state is preserved, so writes made by an earlier statement are visible to later statements according to the same transaction and autocommit behavior that applies to the surrounding entrypoint.
Only the last statement's rows are returned as the public QueryResult. Intermediate results are discarded unless the immediately following statement imports them with FROM PREVIOUS.
Advanced Example
MATCH (u:User)
WHERE u.status = 'active'
RETURN u.uid AS uid, u.segment AS segment;
FROM PREVIOUS AS user_row
MATCH (o:Order {user_uid: user_row.uid})
RETURN
user_row.segment AS segment,
count(o) AS orders,
sum(o.total) AS revenue
ORDER BY revenue DESC
This script first narrows the user population, then the second statement joins the previous rows to order nodes and returns the final aggregated result.
Another common pattern is computing one global value once and reusing it in the next statement:
MATCH (o:Order)
RETURN avg(o.total) AS global_avg_total;
FROM PREVIOUS AS baseline
MATCH (o:Order)
RETURN
o.order_id AS order_id,
o.total AS total,
o.total - baseline.global_avg_total AS delta_from_global_average
ORDER BY delta_from_global_average DESC
That shape is useful when the baseline is easier to audit as its own statement and should not be recomputed in a repeated per-row subquery.
Real Use Cases
- Exploratory graph work where an analyst wants to create a small fixture and immediately inspect the resulting shape.
- Global-baseline analysis where a first statement computes a latest timestamp, maximum value, average, threshold, or compact candidate set and the second statement compares graph rows against it.
- Staged lookups where a first read produces stable business identifiers and the next read expands from those identifiers.
- Assistant-generated live workflows where several simple steps are clearer and safer than one dense query.
- Operational scripts that perform a small ordered set of schema, maintenance, or data statements and only need the final status or verification read.
Real Limitations And Tradeoffs
The caller receives only the final statement result. If earlier rows matter, explicitly pass them to the next statement with
FROM PREVIOUSor return them from the last statement.FROM PREVIOUSonly sees the immediately previous statement's result, not every earlier result in the script.A script with many broad scans can still be slower than one well-shaped Cypher pipeline because each statement has its own bind/optimize/plan/execute cycle. Keep previous results compact and use scripts to avoid repeated work, not to hide repeated all-graph scans.
Persisted abstraction contracts such as abstraction
source_query,relation_query, and feature queries intentionally remain single-statement contracts because they are stored and executed independently.