apache/cassandra · error · InvalidRequestException

Invalid operation (%s) for non collection column %s

Error message

Invalid operation (%s) for non collection column %s

What it means

Cassandra throws this during CQL statement preparation when a collection-specific update operation (e.g. list append/set-by-index, map put, set add) is applied to a column whose type is not a collection. Operation.prepare() validates the receiver column type before binding the operation; non-collection columns only support plain constant set operations.

Source

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

            return false;
        }
    }

    public static class SetElement implements RawUpdate
    {
        private final Term.Raw selector;
        private final Term.Raw value;

        public SetElement(Term.Raw selector, Term.Raw value)
        {
            this.selector = selector;
            this.value = value;
        }

        public Operation prepare(TableMetadata metadata, ColumnMetadata receiver, boolean canReadExistingState) throws InvalidRequestException
        {
            if (!(receiver.type instanceof CollectionType))
                throw new InvalidRequestException(String.format("Invalid operation (%s) for non collection column %s", toString(receiver), receiver.name));
            else if (!(receiver.type.isMultiCell()))
                throw new InvalidRequestException(String.format("Invalid operation (%s) for frozen collection column %s", toString(receiver), receiver.name));

            switch (((CollectionType<?>)receiver.type).kind)
            {
                case LIST:
                    Term idx = selector.prepare(metadata.keyspace, Lists.indexSpecOf(receiver));
                    Term lval = value.prepare(metadata.keyspace, Lists.valueSpecOf(receiver));
                    return new Lists.SetterByIndex(receiver, idx, lval);
                case SET:
                    throw new InvalidRequestException(String.format("Invalid operation (%s) for set column %s", toString(receiver), receiver.name));
                case MAP:
                    Term key = selector.prepare(metadata.keyspace, Maps.keySpecOf(receiver));
                    Term mval = value.prepare(metadata.keyspace, Maps.valueSpecOf(receiver));
                    return new Maps.SetterByKey(receiver, key, mval);
            }
            throw new AssertionError();
        }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Fix the CQL statement to use a plain assignment (SET col = <value>) matching the column's actual scalar type
2. DESCRIBE the table and check the column type; adjust the query or use the correct collection column name
3. If the schema was changed unintentionally, restore the column's collection type (via migration/re-creation with data copy)
4. Correct application-side query builders so collection operation helpers are only used for list/set/map columns

Example fix

// before
UPDATE users SET tags[0] = 'new' WHERE id = 1;  -- tags is text
// after
UPDATE users SET tags = 'new' WHERE id = 1;  -- or make tags a list<text> to use index assignment

// Java: check column type before issuing a collection operation
TableMetadata tm = cluster.getMetadata().getKeyspace(ks).getTable(table);
AbstractType<?> t = tm.getColumn(col).getType();
if (!(t instanceof CollectionType)) throw new IllegalArgumentException(col + " is not a collection; use plain SET col = value");

boolean isCollection(AbstractType<?> t) { return t instanceof CollectionType; }

When it happens

Trigger: UPDATE/INSERT using collection operations like c[k]=v, c+=..., or c=[...] on a column declared as a non-collection type (text, int, UDT, tuple, etc.); e.g. 'UPDATE t SET mytext[0]='x' WHERE ...' or 'UPDATE t SET mytext = mytext + 'a''.

Common situations: Schema drift: the column type was altered from a collection to a scalar (or the query was written for a different table) and old application code still issues collection-style updates; copy-paste between tables with same-named columns of different types.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors

• category %s not found in %s
• GRANT operation is not supported by AllowAllAuthorizer
• REVOKE operation is not supported by AllowAllAuthorizer
• LIST PERMISSIONS operation is not supported by AllowAllAutho
• Invalidate CIDR permissions cache operation not supported by

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