nexyron.graph.project
Generic Description
Create a named snapshot graph projection.
Simple example:
CALL nexyron.graph.project({name: 'people_knows', node_labels: ['Person'], relationship_types: ['KNOWS']})
Catalog and projection procedures manage projected graphs, aggregate views, procedure metadata, and abstraction graph projections used by analytical workflows.
Consumer-Level Explanation
Use nexyron.graph.project when create a named snapshot graph projection is the graph-analysis or operational question you actually need to answer. Keep the call explicit because its YIELD columns, row grain, and required runtime state determine how the rest of the Cypher pipeline can safely compose it. Use these procedures when the query needs to inspect or maintain derived structures explicitly instead of assuming they already exist.
Conceptual Explanation
nexyron.graph.project should be read as one named procedure contract in the broader Nexyron Cypher surface. The procedure call is not only a syntax hook: it defines what runtime state, projection, registry entry, or graph algorithm is being asked to operate, and it determines which output columns downstream YIELD, WITH, and RETURN stages can safely use.
More Detailed Explanation
Use this when you want to run several algorithms against the same filtered subgraph without repeating the same expensive filtering logic each time. It is a query ergonomics and analytical consistency tool
In practical queries, start by deciding the row grain you want after the call: one row per node, one row per path, one row per registry object, one row per artifact, or one row per summary. Then keep that grain explicit with YIELD and named projections. That is the difference between a useful planner-facing example and a vague call that downstream tooling cannot safely compose. For contract-driven procedures, the executable examples on these pages intentionally inspect procedure metadata unless the required named artifacts are created in the same example.
Advanced Example
This example yields named columns from nexyron.graph.project and returns a bounded result shape that downstream planner tooling can compose without guessing column names or row grain.
CALL nexyron.graph.project({name: 'ops_snapshot', node_labels: ['Service'], relationship_types: ['DEPENDS_ON']}) YIELD name, node_count, edge_count
WITH name, node_count, edge_count
MATCH (s:Service)-[e:EMITS]->(m:Metric)
TIME e.ts BETWEEN datetime('2025-01-01T00:00:00Z') AND datetime('2025-01-07T00:00:00Z')
WITH name, node_count, edge_count, date_trunc('hour', e.ts) AS bucket, properties(m) AS payload
RETURN name, node_count, edge_count, bucket, keys(payload) AS payload_keys, unpivot(payload) AS metrics
LIMIT 10
Real Use Cases
- stable algorithm workloads over a curated subgraph
- faster repeated experimentation on the same logical slice
- separating operational graph from analytical working graph
- inventory projected graphs, aggregate views, and procedure metadata before running dependent analytics
- make derived structure maintenance explicit in migrations and operational checks
Real Limitations And Tradeoffs
- a projection is a snapshot, not a live mirror
- you need to refresh it if source data changes
- catalog procedures describe or maintain registered structures; they do not validate that the underlying model is analytically appropriate
- dropping or refreshing derived structures can affect dependent workflows and should be treated as an operational action