Cassandra

Cassandra ALTER MATERIALIZED VIEW Guide for Safe Changes

Learn what ALTER MATERIALIZED VIEW supports in Cassandra, which changes require a drop and recreate, and how to update view options safely.

by Malik Umair Sajjad · 27-May-2023
On this page

Introduction

ALTER MATERIALIZED VIEW in Cassandra is much narrower than many developers expect. You can tune view properties, but you cannot reshape the view definition the way you might in other database systems.

That means most structural changes to a materialized view are not true alters - they are drop-and-recreate operations that should be planned carefully.

What ALTER MATERIALIZED VIEW supports

In Cassandra, ALTER MATERIALIZED VIEW is mainly used with the WITH clause to update view options such as:

  • comment
  • caching
  • compaction
  • compression
  • gc_grace_seconds
  • default_time_to_live

Example:

ALTER MATERIALIZED VIEW ecommerce.orders_by_customer
WITH comment = 'Lookup orders by customer'
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'};

Prerequisites

Before altering a materialized view, you need:

  • a running Cassandra cluster
  • an existing materialized view
  • cqlsh access or DbSchema connected to the cluster
  • confidence that the cluster is healthy enough for schema changes
DbSchema ER diagram designer DbSchema ER diagram designer

Design and visualize
your database schema

Edit referenced records
in related tables

Query your data
visually too

Reuse the SQL
generated

Free Download

What ALTER MATERIALIZED VIEW does not support

ALTER MATERIALIZED VIEW does not let you:

  • change the selected columns
  • change the WHERE ... IS NOT NULL predicates
  • change the view primary key
  • add arbitrary new columns to the view definition
  • rename the materialized view

If you need any of those changes, the practical approach is:

  1. create a replacement materialized view
  2. wait for it to build
  3. move application traffic if needed
  4. drop the old view when it is safe

Alter a materialized view in cqlsh

Here is a simple example that updates metadata and cache settings:

ALTER MATERIALIZED VIEW ecommerce.orders_by_customer
WITH comment = 'Orders accessible by customer id'
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'};

As with tables, be careful when changing map-style options such as compaction or compression. Re-specify all the sub-options you want to retain, not just the one you are changing.

Alter a materialized view in DbSchema

In DbSchema you can:

  1. connect to the Cassandra database
  2. open the materialized view in the model
  3. edit the supported properties
  4. inspect the generated ALTER MATERIALIZED VIEW ... WITH ... statement
  5. deploy the change once you are satisfied

DbSchema is useful here because it helps separate supported property changes from structural edits that actually require recreating the view.

When to recreate instead of alter

Recreate the view instead of altering it when:

  • the alternate primary key must change
  • you need a different extra non-primary-key column
  • the base-table columns included in the view must change
  • the original view definition turned out to be a poor fit for the query pattern

Materialized views already carry write and maintenance cost, so if the structure changes significantly, it is usually better to rebuild the view cleanly than to force incremental changes around a weak design.

Conclusion

ALTER MATERIALIZED VIEW in Cassandra is for property tuning, not for redefining the view. Update supported options with care, but recreate the view when the key shape or selected columns need to change.

That mindset avoids unsupported operations and makes materialized-view maintenance much more predictable.

References