This class encapsulates all the query generators for row slice queries that use a collection of row keys.
There are different row query generators depending on the specific query signature.
e.g
1. Select all columns for all the rows in the row range
2. Select rows with column slice
3. Select rows with column range
4. Select rows using a composite range builder for composite column based schema
Note that for simplicity and brevity, there is another class that handles similar operations for queries that
specify a row range as opposed to a collection of row keys (as is done here).
See
CFRowRangeQueryGen for that implementation. The current class is meant for row slice queries using only row key collections.
Each of the query generators uses the
QueryGenCache so that it can cache the
PreparedStatement as well
for future use by queries with the same signatures.
But one must use this with care, since the subsequent query must have the exact signature, else binding values with
the previously constructed prepared statement will break.
Here is a simple example of a bad query that is not cacheable.
Say that we want a simple query with a column range in it.
ks.prepareQuery(myCF)
.getRow("1")
.withColumnSlice("colStart")
.execute();
In most cases this query lends itself to a CQL3 representation as follows
SELECT * FROM ks.mfCF WHERE KEY = ? AND COLUMN1 > ?;
Now say that we want to perform a successive query (with caching turned ON), but add to the column range query
ks.prepareQuery(myCF)
.getRow("1")
.withColumnSlice("colStart", "colEnd")
.execute();
NOTE THE USE OF BOTH colStart AND colEnd <----- THIS IS A DIFFERENT QUERY SIGNATURE
AND THE CQL QUERY WILL PROBABLY LOOK LIKE
SELECT * FROM ks.mfCF WHERE KEY = ? AND COLUMN1 > ? AND COLUMN1 < ?; <----- NOTE THE EXTRA BIND MARKER AT THE END FOR THE colEnd
If we re-use the previously cached prepared statement, then it will not work for the new query signature. The way out of this is to NOT
use caching with different query signatures.