Details
-
Improvement
-
Status: Resolved
-
Normal
-
Resolution: Fixed
-
None
-
Semantic
-
Normal
-
All
-
None
-
Description
The method ReadCommand::toCQLString doesn't always return queries that are valid CQL. For example, queries for a table without clustering columns always add the WHERE keyword even if there isn't a restriction following it:
CREATE TABLE t (k int PRIMARY KEY, v int); SELECT * FROM t; -- toCQLString 3.0: SELECT * FROM k.t WHERE () = () LIMIT 100 -- toCQLString 3.11/trunk: SELECT * FROM k.t WHERE LIMIT 100
Also, case sensitive names and text values are not properly quoted:
CREATE TABLE "T" ("K" text, "C" text, "V" text, PRIMARY KEY("K", "C")); SELECT * FROM "T" WHERE "K" = 'a' AND "C" = 'b' AND "V" = 'c' ALLOW FILTERING; -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.T WHERE K = a AND V = c AND (C) = (b) LIMIT 100
Similar problems can be found on selections of collection items:
CREATE TABLE k.t (k int, c int, s set<text>, m map<text, text>, PRIMARY KEY(k, c)); SELECT s['a'] FROM t; -- toCQLString trunk: SELECT s[a] FROM k.t LIMIT 100 SELECT * FROM t WHERE m['a'] = 'b' ALLOW FILTERING; -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.t WHERE m[a] = b LIMIT 100
Some similar problems with more impact than the described above are already being addressed in CASSANDRA-16483 and CASSANDRA-16479.
I think we should add more exhaustive JUnit tests for ReadCommand::toCQLString, making sure that its output is parseable and equivalent to the original command. Also, we probably should make sure that we have toCQLString methods in all the query components that are used by ReadCommand::toCQLString (selection, filters, etc.). This way we can use them instead of generic toString methods, making it clear that they are supposed to return valid CQL.
Attachments
Issue Links
- is related to
-
CASSANDRA-16479 Materialized Views: incorrect where clause reported for quoted identifiers
- Resolved
- relates to
-
CASSANDRA-16483 ColumnFilter::toString doesn't return a valid CQL fragment
- Resolved
- links to