nexyron.aggregateview_create
Generic Description
Create a named materialized aggregate view from a stored Cypher query.
Simple example:
CALL nexyron.aggregateview_create({
name: 'sessions_by_country',
query: 'MATCH (u:User)-[:HAS_APP_SESSION]->(s:AppSession) RETURN u.profile.location.country AS country, count(s) AS sessions ORDER BY country'
})
Catalog and projection procedures manage projected graphs, aggregate views, procedure metadata, and abstraction graph projections used by analytical workflows.
Consumer-Level Explanation
Use nexyron.aggregateview_create when you have an aggregate query that you want to materialize, inspect later, refresh explicitly, and in the supported subset maintain exactly across safe committed writes.
This is not just a saved query name. It creates stored metadata plus a materialized result snapshot.
Conceptual Explanation
nexyron.aggregateview_create 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
The procedure stores:
- a unique view name
- the Cypher query text
- the current materialized result
- refresh and change-version metadata
If the query belongs to the supported exact incremental subset, the engine also bootstraps hidden aggregate state that lets later safe writes update the materialized rows without recomputing the whole query.
That subset currently covers direct node scans, direct edge scans, and one-hop edge views with row-local predicates and supported aggregate families. Unsupported shapes still work as materialized views, but they fall back to the stale-plus-refresh model rather than pretending to update exactly.
Advanced Example
CALL nexyron.aggregateview_create({
name: 'engagement_by_country',
query: '
MATCH (u:User)-[:CREATED]->(p:Post)
RETURN u.profile.location.country AS country,
count(DISTINCT p.topic) AS distinct_topics,
top_k(p.topic, 3) AS hottest_topics,
percentile_disc(p.engagement_rate, 0.5) AS median_engagement,
variance(p.engagement_rate) AS engagement_variance
ORDER BY country
'
}) YIELD name, row_count, column_count, refresh_required
RETURN name, row_count, column_count, refresh_required
Real Use Cases
dashboard rollups that should not rerun a large aggregate query every time
product analytics that need stable grouped summaries with explicit refresh control
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 materialized aggregate view is only as current as its refresh or exact incremental maintenance path allows
- arbitrary joins, broad multi-hop expansion, and topology-sensitive shapes are not yet universally exact-maintained
- naming discipline matters because views become durable objects rather than ephemeral query fragments