Cassandra 3.11.1 restricts materialized-view filtering

A materialized-view predicate changes more than which rows a query returns. It can make the existence of a stored view row depend on several independently changing base-table columns. Cassandra 3.11.1 disables creating views with filters on non-primary-key base columns because the implementation cannot support those liveness semantics without changing the storage format.

The Apache release record dates 3.11.1 to 10 October. Its upgrade notes describe the restriction and an explicitly unsafe exception for append-only use. This is a correction to materialized-view creation, not a general removal of filtering from CQL queries.

I find Cassandra's distributed deployment model compelling when the system requires it. That interest does not make every derived-data capability equally suitable for an application. A feature that changes whether a row exists needs a representation that can preserve that decision as the underlying columns change.

The view row depends on several base columns

The issue behind the restriction identifies the combination that causes trouble. Liveness can depend on multiple filtered non-key columns and on the base-table column used in the view's primary key. The issue proposes stepping back from the filtering capability introduced by CASSANDRA-10368 and reconsidering it alongside support for multiple non-key columns in a view's clustering key.

These are related design questions because a view stores its own rows. Maintaining a predicate over mutable base data requires the database to update that stored representation when the relevant base columns change. If the representation cannot express the necessary liveness relationships, accepting the schema gives the application a capability whose maintenance semantics are incomplete.

The release notes therefore make the restriction explicit at creation time. They do not describe the change as a query-performance decision or as protection against an expensive scan. The stated problem is correctness, and the proposed general solution requires a storage-format change. That is a different category of limitation from deciding that a query costs too much.

For append-only workloads, the notes retain a startup override:

-Dcassandra.mv.allow_filtering_nonkey_columns_unsafe=true

The property name and its documented scope matter. It permits the restricted capability for the append-only use case described by the maintainers. It does not claim to make the general update and deletion semantics correct. An application that later introduces mutations outside that model would be depending on behavior the restriction was added to exclude.

Timestamp changes also affect existing views

The same release notes contain materialized-view guidance for users upgrading from 3.X or versions below 3.0.15. Cassandra no longer allows dropping columns from tables that have materialized views. The notes also describe a change to the computation of view timestamps, with a specific interaction involving repair and old column deletions.

The problematic column participates in the view's primary key but not in the base table's primary key. A deletion of that column might have been missed before the upgrade and arrive through base-table repair afterward. Under the condition described in the notes, that old deletion may fail to appear in the view after the timestamp change.

The documented responses depend on when the maintenance happens. Repairing the base table on all nodes before upgrading addresses the described missed deletions before the transition. After upgrading, the notes identify repairing the views or dropping and recreating them as ways to correct potential inconsistencies. These are concrete consequences of changing the derived-data timestamp rules.

Another warning concerns deletions of base columns that the view does not select. The notes advise against those deletions in the affected circumstances because they may not be reflected correctly in the view. That warning is distinct from the new restriction on filtered view creation. Reading only the first upgrade bullet would miss an issue relevant to existing schemas.

I regard this level of specificity as necessary for evaluating a materialized-view deployment. The base table and its derived rows have separate maintenance histories. A correction to how new mutations are represented does not automatically settle every older deletion that can still arrive through repair.

The maintenance release also fixes retained memory

The 3.11.1 changelog includes a BTree.Builder memory leak under CASSANDRA-13754. The original report describes heap analysis after repeated out-of-memory failures in the reporter's development environment. More than 10 GB of a 12 GB heap appeared in thread-local members of Netty FastThreadLocalThread instances.

Those figures belong to the issue reporter's environment. They establish a concrete observation behind the correction, without defining how much memory every affected installation would retain. The release entry identifies the builder leak as a separate maintenance concern from view semantics.

For users of 3.11, the release combines memory-management corrections with tighter limits on accepted materialized-view definitions. Existing views also require attention to the documented deletion and timestamp conditions during an upgrade. The new creation restriction prevents another schema from depending on general liveness semantics that the current storage representation cannot support.