Feature Request: Generate SELECT statements with explicit columns instead of SELECT *

[Neldering]

Summary:
Spring Data Cassandra's CassandraQueryCreator currently generates SELECT * queries by default. This can lead to performance issues and make applications more vulnerable to schema changes, especially when working with wide tables or older versions of Cassandra or its driver that lack robust schema handling.

Problem Statement:
Using SELECT * in generated queries causes the following issues:

• Query execution and deserialization are slower

• Schema changes (e.g., adding new columns) may introduce bugs or unexpected behavior

• Older Cassandra drivers (prior to 4.x) are less tolerant of schema drift

Proposed Solution:
Update CassandraQueryCreator to generate queries with explicitly listed columns based on the entity’s mapped fields. The framework already has access to this metadata via the mapping context.

Optionally, this behavior could be toggled via a configuration property, such as:
spring.data.cassandra.query.explicit-columns=true

Benefits:

• Reduced query execution time and network I/O

• Increased stability in environments with schema changes

• Better compatibility with older Cassandra versions and drivers

• Follows best practices for Cassandra query design

Environment:

• Spring Data Cassandra: 4.1.x

• Cassandra: 3.x / 4.x

• Cassandra Java Driver: 4.14 and earlier

Affected class: org.springframework.data.cassandra.repository.query.CassandraQueryCreator

Related:
While Spring Data 4.x offers improved schema handling, this change would benefit users on legacy stacks or where upgrading the Cassandra driver is not feasible.

[mp911de]

Spring Data Cassandra considers projections and Query.columns for initial selection of columns.

When selecting an entity, we select all columns because we cannot make tight assumptions over later usage. Generally speaking, an entity can make use of @Value to access other than mapped columns in its constructor or when setting properties.

Also, there can be registered Converter<Row, …> converters and their implementation is opaque to StatementFactory. We can however introduce an optimization to StatementFactory that defaults to a different selection when creating statements for entity selection.

[Neldering]

@mp911de i would love to help with the update if you are open to it

[mp911de]

Sounds good, feel free to submit a pull request along with tests. The imperative, asynchronous and reactive template APIs are affected. I’ll be out for two weeks, so that you know why I won’t reply timely. Am 18. Juli 2025, 17:15 +0200 schrieb Nicolas Eldering ***@***.***>:

…

Neldering left a comment (spring-projects/spring-data-cassandra#1590) @mp911de i would love to help with the update if you are open to it — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>