---
title: nexyron.aggregateview_drop
url: https://nexyron.tech/docs/cypher/procedures/catalog-and-projections/nexyron-aggregateview-drop
description: Drop a named materialized aggregate view and remove its stored metadata and rows.
---

# nexyron.aggregateview_drop

## Generic Description

Drop a named materialized aggregate view and remove its stored metadata and rows.

Simple example:

```cypher
CALL nexyron.aggregateview_drop({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_drop` when a materialized aggregate view is no longer needed and you want to remove it explicitly.

This is the lifecycle cleanup step that complements create, list, read, and refresh. Use these procedures when the query needs to inspect or maintain derived structures explicitly instead of assuming they already exist.

## Conceptual Explanation

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

Aggregate views are durable objects in the database lifecycle, not just one-off query aliases. That means they need explicit deletion semantics.

Dropping a view removes:

-   the stored definition
-   the current materialized rows
-   associated freshness and incremental-maintenance metadata

## Advanced Example

```cypher
CALL nexyron.aggregateview_drop({name: 'engagement_by_country'})
YIELD name
RETURN name
```

## Real Use Cases

-   retiring obsolete dashboard summaries
-   replacing an old view definition with a new canonical one
-   keeping aggregate-view inventory small and understandable
-   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

-   dropping a view is destructive for that view’s stored result and metadata
-   if the view is still used by dashboards or operational queries, callers will need to recreate it or switch to another source
-   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