---
title: nexyron.aggregateview_refresh
url: https://nexyron.tech/docs/cypher/procedures/catalog-and-projections/nexyron-aggregateview-refresh
description: Refresh a named materialized aggregate view by recomputing its stored result from the current source data.
---

# nexyron.aggregateview_refresh

## Generic Description

Refresh a named materialized aggregate view by recomputing its stored result from the current source data.

Simple example:

```cypher
CALL nexyron.aggregateview_refresh({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_refresh` when you want to force recomputation of a materialized aggregate view and clear any stale boundary.

This is the explicit maintenance tool for views whose source shape is not on the exact incremental subset or whose cached result you want to rebuild intentionally.

## Conceptual Explanation

`nexyron.aggregateview_refresh` 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

Refresh matters because Nexyron deliberately does not pretend every aggregate query can be updated incrementally and exactly.

The current design is:

-   supported safe subset: exact maintenance where the engine can prove the update path
-   unsupported shapes: mark stale and require explicit refresh

That is the correct architecture here because it keeps correctness ahead of coverage.

## Advanced Example

```cypher
CALL nexyron.aggregateview_refresh({name: 'engagement_by_country'})
YIELD name, row_count, column_count, last_refresh_version, current_change_version, refresh_required
RETURN name,
       row_count,
       column_count,
       last_refresh_version,
       current_change_version,
       refresh_required
```

## Real Use Cases

-   recomputing a view after a batch load or a broad mutation wave
-   clearing `refresh_required` after an unsupported mutation shape
-   rebuilding materialized summary rows during operational maintenance
-   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

-   refresh recomputes the view query, so it is more expensive than an exact incremental delta when the exact subset is available
-   forcing refresh too often can erase the value of materialization
-   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