cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andres de la Peña (Jira) <>
Subject [jira] [Commented] (CASSANDRA-16510) Make ReadCommand::toCQLString return valid CQL
Date Mon, 05 Jul 2021 15:06:00 GMT


Andres de la Peña commented on CASSANDRA-16510:

[~blerer] Thanks for the review. I have rebased the patch and CI is running ([j8|] and
with a few multiplexer runs for the new {{AbstractReadQueryToCQLStringTest}}.

Do we agree on applying this only to trunk?

> Make ReadCommand::toCQLString return valid CQL
> ----------------------------------------------
>                 Key: CASSANDRA-16510
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL/Syntax, Observability/Logging
>            Reporter: Andres de la Peña
>            Assignee: Andres de la Peña
>            Priority: Normal
>             Fix For: 4.1
>          Time Spent: 10m
>  Remaining Estimate: 0h
> 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:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, v int);
> -- toCQLString 3.0:        SELECT * FROM k.t WHERE () = () LIMIT 100
> -- toCQLString 3.11/trunk: SELECT * FROM k.t WHERE  LIMIT 100
> {code}
> Also, case sensitive names and text values are not properly quoted:
> {code:java}
> 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)
> {code}
> Similar problems can be found on selections of collection items:
> {code:java}
> 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
> -- toCQLString 3.0/3.11/trunk: SELECT * FROM k.t WHERE m[a] = b LIMIT 100
> {code}
> 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.

This message was sent by Atlassian Jira

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message