apache/cassandra · error · InvalidRequestException

frozen<> is only allowed on collections, tuples, and user-de

Error message

frozen<> is only allowed on collections, tuples, and user-defined types (got %s)

What it means

In CQL3Type.Raw (the parsed, not-yet-prepared type), freeze() is meant only for collections, tuples, and UDTs which support frozen semantics. Calling frozen<> on any other type (e.g. int, text, uuid) throws InvalidRequestException because freezing a scalar is meaningless — frozen controls whether the type's internal structure can be updated after being stored in a collection/UDT cell.

Source

Thrown at src/java/org/apache/cassandra/cql3/CQL3Type.java:687

        public boolean isImplicitlyFrozen()
        {
            return isTuple() || isVector();
        }

        public boolean isVector()
        {
            return false;
        }

        public String keyspace()
        {
            return null;
        }

        public Raw freeze()
        {
            String message = String.format("frozen<> is only allowed on collections, tuples, and user-defined types (got %s)", this);
            throw new InvalidRequestException(message);
        }

        public abstract void validate(ClientState state, String name);

        public CQL3Type prepare(String keyspace)
        {
            KeyspaceMetadata ksm = Schema.instance.getKeyspaceMetadata(keyspace);
            if (ksm == null)
                throw new ConfigurationException(String.format("Keyspace %s doesn't exist", keyspace));
            return prepare(keyspace, ksm.types);
        }

        public abstract CQL3Type prepare(String keyspace, Types udts) throws InvalidRequestException;

        public CQL3Type prepareInternal(String keyspace, Types udts) throws InvalidRequestException
        {
            return prepare(keyspace, udts);
        }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Remove frozen<> from the non-collection type: use plain int, text, etc.
Apply frozen<> only to collections (list/set/map), tuples, and UDTs
If you intended multi-cell behavior for a collection, use frozen<list<int>>-style only where required by the schema design

Example fix

// before
CREATE TABLE t (k int PRIMARY KEY, v frozen<int>);
// after
CREATE TABLE t (k int PRIMARY KEY, v int);

Defensive patterns

Strategy: validation

Validate before calling

// client-side check before DDL
boolean freezable = type instanceof CollectionType || type instanceof TupleType || type instanceof UserType;
if (!freezable) throw new InvalidRequestException("frozen<> not allowed on " + type);

Try / catch

try { session.execute(schemaDdl); } catch (InvalidRequestException e) { if (e.getMessage().contains("frozen")) fixDdlAndRetry(); }

Prevention

Only use frozen<> with list/set/map, tuple, and UDT types
Review generated DDL scripts for stray frozen<> wrappers
Remember frozen only matters for types with internal structure

When it happens

Trigger: A CQL statement like CREATE TABLE t (k int PRIMARY KEY, v frozen<int>); or frozen<text>; — applying frozen<> to a non-collection type in a schema definition.

Common situations: Copy-paste schema edits adding frozen<> indiscriminately; misunderstanding that frozen applies to all types; migration scripts generated from schemas of other databases.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

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