-
Notifications
You must be signed in to change notification settings - Fork 310
Prepared IN
queries should support bind markers
#1172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks a lot. I wasn't aware that Cassandra is able to consume collections/arrays within a single placeholder. The issue we have is a bit that the statement factory isn't aware that the statement is going to be used as a prepared statement. Maybe we we can generally provide collections as a single parameter but then the question remains how this would work with inline parameter rendering. |
Thanks for the response. Sounds fairly involved and I don't have much familiarity with the codebase. I would really like to fix this but I think it's best I leave it to the professionals :-) Update: Ideas making use of the BindMarker accepting InRelationBuilder::in. https://github.com/samueldlightfoot/spring-data-cassandra/tree/1172-in-query-bindmarkers |
Hi Mark, any thoughts on this? Happy to help out if you have any ideas. |
Feel free to submit a pull request. I hadn't had the bandwidth yet to wrap my head around it. |
IN
queries should support bind markers
Statements generated for IN queries do not use the bindMarker(?) for the collection of values provided for the IN clause. When using prepared statements this means we are creating a prepared statement for each IN query with different parameters. This soon bloats the prepared statement cache when you are selecting by different parameters.
This parameterization is supported in Cassandra:
https://issues.apache.org/jira/browse/CASSANDRA-4210
Expected:
SELECT * FROM Users WHERE id IN ?
Actual:
SELECT * FROM Users WHERE id IN ('id1', 'id2')
Looking in statement factory IN queries that take a collection are handled differently:
Example test: 537f96b
I'm happy to have a go at fixing this if we are in agreement it is a bug.
The text was updated successfully, but these errors were encountered: