apache/cassandra · error · InvalidRequestException

Modification is not supported by table " + metadata

Error message

Modification is not supported by table " + metadata

What it means

Virtual tables in Cassandra are read-only system views exposed through the virtual table framework. CollectionVirtualTableAdapter.apply is the write hook, and it unconditionally rejects any modification attempt against the virtual table it adapts. This is intentional: virtual tables reflect live in-memory system state and cannot be written to.

Source

Thrown at src/java/org/apache/cassandra/db/virtual/CollectionVirtualTableAdapter.java:579

        return ((AbstractType<T>) type).decompose(value);
    }

    @SuppressWarnings("unchecked")
    private static <T> T compose(AbstractType<?> type, ByteBuffer value)
    {
        return (T) type.compose(value);
    }

    @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("Truncate is not supported by table " + metadata);
    }
}

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Do not write to virtual tables; they are read-only views over runtime state.
  2. Check the table with `DESCRIBE TABLE` / query system_schema.virtual_tables to confirm it is virtual.
  3. If you intended to change underlying state, modify the real configuration or feature that the virtual table exposes (e.g. nodetool, config in cassandra.yaml).
  4. Fix any tooling/table-name typos that route writes to a virtual table.

Example fix

// before
INSERT INTO system_views.threads (thread_id, thread_name) VALUES (1, 'x');
// after
SELECT * FROM system_views.threads WHERE thread_name = 'x';
Defensive patterns

Strategy: validation

Validate before calling

// CQL-side guard: confirm the table is not virtual before writing
Row row = session.execute("SELECT kind FROM system_schema.tables WHERE keyspace_name=? AND table_name=?", ks, table).one();
if (row != null && "virtual".equals(row.getString("kind")))
    throw new IllegalStateException(table + " is a virtual table and cannot be modified");

Try / catch

try { session.execute(writeStmt); }
catch (com.datastax.oss.driver.api.core.servererrors.InvalidQueryException e) {
    if (e.getMessage().contains("Modification is not supported")) { /* skip virtual table */ }
    else throw e;
}

Prevention

When it happens

Trigger: Executing any INSERT, UPDATE, DELETE, or BATCH statement that targets a virtual table (e.g. writing to system_views.* or a collection-backed virtual table). The CQL statement reaches VirtualTable.apply(PartitionUpdate) and immediately throws.

Common situations: Scripts or migration tools treating virtual tables like normal tables; typos in table names that resolve to a virtual table instead of a real one; automation that assumed system_views tables were writable.

Related errors

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