nexyron.aggregateview_list
Generic Description
List materialized aggregate views and their current metadata.
Simple example:
CALL nexyron.aggregateview_list()
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_list when you want inventory and freshness visibility for stored aggregate views.
It is the procedure you use to answer questions like:
- what views exist?
- what query does each view represent?
- how many rows and columns are currently materialized?
- is the view fresh or refresh-required?
Conceptual Explanation
nexyron.aggregateview_list 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 metadata surface includes:
namequeryrow_countcolumn_countrefreshed_at_mslast_refresh_versioncurrent_change_versionrefresh_required
That is important because materialized aggregation is only operationally useful if you can see freshness state directly instead of guessing whether a cached result is still trustworthy.
Advanced Example
CALL nexyron.aggregateview_list()
YIELD name, row_count, column_count, last_refresh_version, current_change_version, refresh_required
WITH *
WHERE refresh_required OR row_count > 0
RETURN name,
row_count,
column_count,
current_change_version - last_refresh_version AS version_gap,
refresh_required
ORDER BY refresh_required DESC, version_gap DESC, name
Real Use Cases
- admin UIs that show which analytical summaries are currently materialized
- operational debugging of stale-versus-fresh aggregate views
- lifecycle cleanup and refresh planning
- 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
- the listing tells you freshness metadata, not whether the underlying query shape belongs to the exact incremental subset
- inventory is only useful if view naming stays disciplined and descriptive
- 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