[ 
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17344650#comment-17344650
 ] 

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

Now I'm reading the right PR, sorry for the confusion. Having the test to 
verify that the two lists of reserved keywords is nice. However I'm a bit 
concerned about parsing the Java file since it might be a bit brittle, a single 
line comment on {{ReservedKeywords}} might break it, for example:
{code:java}
    @VisibleForTesting
    static final String[] reservedKeywords = new String[]
                                                     {
                                                     "SELECT", // this is the 
most important keyword
                                                     "FROM",
                                                     "WHERE",
{code}
or
{code:java}
    @VisibleForTesting
    static final String[] reservedKeywords = new String[]
                                                     {
                                                     "SELECT",
                                                    // "JOIN",
                                                     "FROM",
                                                     "WHERE",
{code}
would break it, and it wouldn't be detected until the test is run. This is 
unlikely to happen and not very hard to fix if it happens, but we could add a 
comment mentioning the existence of {{test_cql_reserved_keywords}} in 
{{ReservedKeywords}} to warn maintainers.

Alternatively, I wonder if we could just place the list of reserved keywords in 
a unique plain text file, so both {{cqlhandling.py}} and {{ReservedKeywords}} 
can read it. That way we wouldn't need to maintain two copies of the same list 
and a test to detect inconsistencies between them. Indeed the test parsing code 
wouldn't even be necessary, wdyt?

> cqlsh 6.0.0 treats "config" as a reserved keyword
> -------------------------------------------------
>
>                 Key: CASSANDRA-16659
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
>             Project: Cassandra
>          Issue Type: Bug
>          Components: CQL/Interpreter
>            Reporter: Bowen Song
>            Assignee: Ekaterina Dimitrova
>            Priority: Normal
>             Fix For: 4.0-rc
>
>
> Based on the information 
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
>  from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not 
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> cqlsh:config> 
> {noformat}
> For reference:
>  * Non-reserved keywords, such as "all", don't have the above problem. They 
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> cqlsh:all> 
> {noformat}
>  * Reserved keywords, such as "add", can be used as keyspace name but 
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create 
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be 
> used in the "create keyspace" statement without quoting, but requires quoting 
> in the "use" and "desc" statements.
>  
>  I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when 
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> 
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy', 
> 'replication_factor': '1'}  AND durable_writes = true;
> cqlsh:config> 
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to