nexyron.aggregateview_drop

Generic Description

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

Simple example:

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

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