apache/cassandra · error · InvalidRequestException

Element selection not supported for column %s of type %s

Error message

Element selection not supported for column %s of type %s

What it means

In transactional row data references, element selection (e.g. `m[key]` or `l[i]`) is only supported for MAP and LIST collections. getValueReceiver throws this InvalidRequestException for any other collection kind (e.g. SET) when an element path is supplied.

Source

Thrown at src/java/org/apache/cassandra/cql3/transactions/RowDataReference.java:137

        {
            forMetadata = forMetadata.withNewType(getFieldSelectionType());
        }
        return forMetadata;
    }

    public ColumnSpecification getValueReceiver()
    {
        if (isElementSelection())
        {
            CollectionType.Kind collectionKind = ((CollectionType<?>) column.type).kind;
            switch (collectionKind)
            {
                case LIST:
                    return Lists.valueSpecOf(column);
                case MAP:
                    return Maps.valueSpecOf(column);
                default:
                    throw new InvalidRequestException(String.format("Element selection not supported for column %s of type %s" ,
                                                                    column.name, collectionKind));
            }
        }
        else if (isFieldSelection())
        {
            return getFieldSelectionSpec();
        }

        return column;
    }

    public boolean isElementSelection()
    {
        return elementPath != null && column.type.isCollection();
    }

    public boolean isFieldSelection()
    {

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Use map or list columns when per-element transactional access is needed.
  2. Reference the whole SET column value instead of an element.
  3. Unfreeze/restructure the schema: replace set<text> with map<text,text> if keyed access is required.

Example fix

// before
UPDATE ks.t SET tags['x'] = '1' WHERE ...; // tags is set<text>
// after
UPDATE ks.t SET tags = tags + {'x'} WHERE ...; // whole-collection op, or use map<text,text>
Defensive patterns

Strategy: validation

Validate before calling

if (column.type.asCQL3Type().getKind() == SET && hasElementSelection(column))
    throw new IllegalArgumentException("Element selection not supported for set column " + column.name);

Try / catch

try { session.execute(txnStmt); } catch (InvalidRequestException e) { if (e.getMessage().contains("Element selection not supported")) rewriteAsWholeCollection(); else throw e; }

Prevention

When it happens

Trigger: A transaction partial-reference like `SELECT col[k]` or a TxnUpdate referencing an element of a SET column, or a non-collection column misused with an element selector.

Common situations: Trying to read/update a single element of a set inside a lightweight-transaction/transaction block; element selection attempted on a frozen collection where per-element access isn't meaningful.

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/9a19d2304a169a8c. Report an issue: GitHub.