nexyron.aggregateview_read

Generic Description

Read the current materialized rows of a named aggregate view.

Simple example:

CALL nexyron.aggregateview_read({name: 'sessions_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_read when you want the already materialized result of a named aggregate view instead of rerunning the original aggregate query.

This is the normal consumption path after a view has been created. Use these procedures when the query needs to inspect or maintain derived structures explicitly instead of assuming they already exist.

Conceptual Explanation

nexyron.aggregateview_read 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

nexyron.aggregateview_read returns the stored result rows with the column layout of the materialized query.

That matters because the view can be consumed as a row-producing Cypher source:

CALL nexyron.aggregateview_read({name: 'sessions_by_country'}) YIELD country, sessions
RETURN country, sessions
ORDER BY sessions DESC

This is how materialized aggregate views stay part of the same Cypher pipeline rather than becoming a separate API surface.

Advanced Example

CALL nexyron.aggregateview_read({name: 'engagement_by_country'})
YIELD country, distinct_topics, hottest_topics, median_engagement, engagement_variance
RETURN country,
       distinct_topics,
       hottest_topics,
       median_engagement,
       engagement_variance
ORDER BY median_engagement DESC

Real Use Cases

• reading dashboard-ready grouped metrics without re-running the source query
• joining a materialized aggregate result back into later Cypher stages
• validating exact incremental maintenance after writes in operational tests
• 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

• read gives you the current stored snapshot, not an implicit recomputation
• if a view is marked refresh_required, the rows may be stale relative to current data
• 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