apache/cassandra · error · InvalidRequestException

Modification is not supported by table " + metadata

Error message

Modification is not supported by table " + metadata

What it means

AbstractVirtualTable's default apply() implementation rejects all partition mutations. Virtual tables are read-only system views backed by in-memory data, so any INSERT/UPDATE/DELETE against them is invalid and rejected with InvalidRequestException at query preparation/execution time.

Source

Thrown at src/java/org/apache/cassandra/db/virtual/AbstractVirtualTable.java:130

            @Override
            public boolean hasNext()
            {
                return iterator.hasNext();
            }

            @Override
            public TableMetadata metadata()
            {
                return metadata;
            }
        };
    }

    @Override
    public void apply(PartitionUpdate update)
    {
        throw new InvalidRequestException("Modification is not supported by table " + metadata);
    }

    @Override
    public void truncate()
    {
        throw new InvalidRequestException("Truncation is not supported by table " + metadata);
    }

    @Override
    public String toString()
    {
        return metadata().toString();
    }

    public interface DataSet
    {
        boolean isEmpty();
        Partition getPartition(DecoratedKey partitionKey);

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Do not issue modifications against virtual tables; query them with SELECT only.
  2. If the intent is to change configuration, find the corresponding nodetool command or JMX operation that mutates the underlying setting.
  3. If implementing a custom virtual table that must accept writes, override apply(PartitionUpdate) in your AbstractVirtualTable subclass.
  4. Filter virtual tables out of tooling by checking TableMetadata.VIRTUAL flag before generating DML.

Example fix

// before
session.execute("UPDATE system_views.sessions SET timeout = 600 WHERE key = 'x'");
// after
// virtual tables are read-only; mutate via nodetool/JMX instead
session.execute("SELECT * FROM system_views.sessions WHERE key = 'x'");
Defensive patterns

Strategy: validation

Validate before calling

boolean isVirtual = session.execute("SELECT * FROM system_schema.tables WHERE keyspace_name = ? AND table_name = ?", ks, table).all().stream().noneMatch(r -> r.getBool("flags").toString().contains("virtual")) && ks.startsWith("system");

Type guard

boolean isModifiable(TableMetadata m) { return !m.virtual; }

Try / catch

try { session.execute(update); } catch (com.datastax.driver.core.exceptions.InvalidQueryException e) { if (e.getMessage().contains("Modification is not supported")) { /* reroute to admin operation */ } else throw e; }

Prevention

When it happens

Trigger: Executing an INSERT, UPDATE, DELETE, or BATCH containing a modification against a virtual table (e.g. system_views.*, system.local virtual tables) whose table class does not override apply().

Common situations: Scripts or application code that assume virtual tables behave like normal tables; migration tooling trying to 'fix' rows in system_views or system_virtual_schema; automation that generates DML for any table returned by system_schema.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/9814b23f2e2f760c. Report an issue: GitHub.