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
- Use map or list columns when per-element transactional access is needed.
- Reference the whole SET column value instead of an element.
- 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
- Use map/list for per-element transactional access
- Avoid element selectors on sets and frozen collections
- Review transaction references for collection kinds
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
- Value for a map addition has to be a map, but was: '%s'
- Value for a map substraction has to be a set, but was: '%s'
- Invalid operation (%s) for non list column %s
- Invalid deletion operation for non collection column %s
- Invalid deletion operation for frozen collection column %s
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/9a19d2304a169a8c.
Report an issue: GitHub.