apache/cassandra · error · InvalidRequestException

Frozen UDT column does not support field deletions

Error message

Frozen UDT column %s does not support field deletions

What it means

Cassandra's Operation.prepare() validates a DELETE of a UDT field against the column's type. Frozen UDTs are stored as a single non-multi-cell value, so individual fields cannot be deleted; only non-frozen (multi-cell) UDTs support field-level deletions. The error is raised at statement-preparation time, before execution.

Solutions

  1. Remove 'frozen<' from the UDT column definition and migrate: ALTER is not supported, so create a new non-frozen column/table and copy data, or
  2. Replace the field deletion with a full frozen-value rewrite: UPDATE users SET address = <entire new UDT value> WHERE ...

Example fix

// before (frozen UDT)
address frozen<address>
DELETE address.street FROM users WHERE id = 1; // fails
// after (non-frozen UDT)
address address -- created without frozen<>
DELETE address.street FROM users WHERE id = 1;
Defensive patterns

Strategy: validation

Validate before calling

if (receiver.type.isUDT() && !receiver.type.isMultiCell()) throw new IllegalArgumentException("frozen UDT column " + receiver.name + " does not support field deletions");

Type guard

boolean supportsFieldDelete = col.getType() instanceof UserType ut && ut.isMultiCell();

Try / catch

try { session.execute(deleteFieldStmt); } catch (InvalidRequestException e) { if (e.getMessage().contains("does not support field deletions")) { /* rewrite whole value */ } }

Prevention

When it happens

Trigger: Executing a statement like DELETE address.street FROM users WHERE ... where the 'address' column is a frozen UDT (e.g. frozen<address>), or a non-UDT column passes the earlier check with isMultiCell() false.

Common situations: Schema migration made a UDT column frozen (or it was created frozen for compaction/performance reasons) while application code assumes non-frozen field-updatable semantics; copying CQL from a non-frozen table to a frozen one.

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/32446b47b36e07d6. Report an issue: GitHub.

Appendix: source

Thrown at src/java/org/apache/cassandra/cql3/Operation.java:565

        private final FieldIdentifier field;

        public FieldDeletion(ColumnIdentifier id, FieldIdentifier field)
        {
            this.id = id;
            this.field = field;
        }

        public ColumnIdentifier affectedColumn()
        {
            return id;
        }

        public Operation prepare(String keyspace, ColumnMetadata receiver, TableMetadata metadata) throws InvalidRequestException
        {
            if (!receiver.type.isUDT())
                throw new InvalidRequestException(String.format("Invalid field deletion operation for non-UDT column %s", receiver.name));
            else if (!receiver.type.isMultiCell())
                throw new InvalidRequestException(String.format("Frozen UDT column %s does not support field deletions", receiver.name));

            if (((UserType) receiver.type).fieldPosition(field) == -1)
                throw new InvalidRequestException(String.format("UDT column %s does not have a field named %s", receiver.name, field));

            return new UserTypes.DeleterByField(receiver, field);
        }
    }
}

View on GitHub (pinned to 88fd0f6a0e)