apache/cassandra · error · InvalidRequestException

Cannot restrict clustering columns when selecting only…

Error message

Cannot restrict clustering columns when selecting only static columns

What it means

Thrown when a SELECT that reads only static columns includes restrictions on clustering columns. Since static columns have a single value per partition, clustering restrictions would not change the result set, so they are rejected as meaningless.

Solutions

1. Drop the clustering column restrictions and query by partition key only: `SELECT k, s FROM t WHERE k=0`.
2. If per-row data is also needed, project regular columns too so clustering restrictions become valid.
3. Check the query builder to omit clustering predicates when only static columns are selected.
4. Select DISTINCT with partition-key restrictions if you want one row per partition.

Example fix

// before
SELECT k, s FROM t WHERE k = 0 AND c = 1; -- s is static
// after
SELECT k, s FROM t WHERE k = 0;

if (selectsOnlyStaticColumns(stmt) && hasClusteringRestrictions(whereClause)) throw new IllegalArgumentException("static-only SELECT cannot restrict clustering columns");

When it happens

Trigger: `SELECT k, s FROM t WHERE k=0 AND c=1` where s is static and c is clustering; queries built generically that append clustering predicates to static-only projections.

Common situations: Application templates generating WHERE clauses from all known columns; developers expecting static reads to be filterable per clustering row; ORM-generated queries including every key column.

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

• Invalid restrictions on clustering columns since the
• A TTL must be greater or equal to 0, but was
• Attempted to delete an element from a list which is null
• Cannot mix IF conditions and
• Cannot set on non-regular table ' .

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

Appendix: source

Thrown at src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java:295

            filterRestrictions.add(partitionKeyRestrictions);

        if (selectsOnlyStaticColumns && hasClusteringColumnsRestrictions())
        {
            // If the only updated/deleted columns are static, then we don't need clustering columns.
            // And in fact, unless it is an INSERT, we reject if clustering colums are provided as that
            // suggest something unintended. For instance, given:
            //   CREATE TABLE t (k int, v int, s int static, PRIMARY KEY (k, v))
            // it can make sense to do:
            //   INSERT INTO t(k, v, s) VALUES (0, 1, 2)
            // but both
            //   UPDATE t SET s = 3 WHERE k = 0 AND v = 1
            //   DELETE v FROM t WHERE k = 0 AND v = 1
            // sounds like you don't really understand what your are doing.
            if (type.isDelete() || type.isUpdate())
                throw invalidRequest("Invalid restrictions on clustering columns since the %s statement modifies only static columns",
                                     type);
            if (type.isSelect())
                throw invalidRequest("Cannot restrict clustering columns when selecting only static columns");
        }

        processClusteringColumnsRestrictions(hasQueriableIndex,
                                             selectsOnlyStaticColumns,
                                             forView,
                                             allowFiltering);

        // Covers indexes on the first clustering column (among others).
        if (isKeyRange && hasQueriableClusteringColumnIndex)
            usesSecondaryIndexing = true;

        if (usesSecondaryIndexing || clusteringColumnsRestrictions.needFiltering())
            filterRestrictions.add(clusteringColumnsRestrictions);

        // Even if usesSecondaryIndexing is false at this point, we'll still have to use one if
        // there is restrictions not covered by the PK.
        if (!nonPrimaryKeyRestrictions.isEmpty())
        {

View on GitHub (pinned to 88fd0f6a0e)