[
https://issues.apache.org/jira/browse/CASSANDRA-19956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17941028#comment-17941028
]
Pedro Gordo edited comment on CASSANDRA-19956 at 4/4/25 4:57 PM:
-----------------------------------------------------------------
Yes, that also works. I opted by keeping the move from the old function in
utils, to cqlhandling.py, since it was not being used by anything else. Also
kept the the new comments which are clearer about its intent.
Re-run tests: [^cqlshlib_tests.txt]
PR: [https://github.com/apache/cassandra/pull/4052]
Just for future reference, while trying to understand how
{{cql_massage_tokens}} works, I noticed it was called from 2 places:
* pylib/cqlshlib/cqlhandling.py:136
* pylib/cqlshlib/cqlhandling.py:128
These two calls happen if we try a SELECT, for instance, with the following
stacks:
```
cql_split_statements, cqlhandling.py:136
onecmd, cqlshmain.py:744
### SAME STACK ###
cmdloop, cqlshmain.py:728
main, cqlshmain.py:2352
<module>, cqlsh.py:88
### SAME STACK ###
```
and
```
cql_parse, cqlhandling.py:128
parse_for_select_meta, cqlshmain.py:862
perform_simple_statement, cqlshmain.py:915
perform_statement, cqlshmain.py:840
do_select, cqlshmain.py:834
handle_statement, cqlshmain.py:802
onecmd, cqlshmain.py:765
### SAME STACK ###
cmdloop, cqlshmain.py:728
main, cqlshmain.py:2352
<module>, cqlsh.py:88
### SAME STACK ###
```
I don't understand why we're parsing the tokens a 2nd time, since we already do
it at cqlhandling.py:136, but I'll look into this closer separately.
was (Author: pedro_gordo):
Yes, that also works. I opted by keeping the move from the old function in
utils, to cqlhandling.py, since it was not being used by anything else. Also
kept the the new comments which are clearer about its intent.
Re-run tests: [^cqlshlib_tests.txt]
PR: [https://github.com/apache/cassandra/pull/4052]
Just for future reference, while trying to understand how
{{cql_massage_tokens}} works, I noticed it was called from 2 places:
* pylib/cqlshlib/cqlhandling.py:136
* pylib/cqlshlib/cqlhandling.py:128
These two calls happen if we try a SELECT, for instance, with the following
stacks:
cql_split_statements, cqlhandling.py:136
onecmd, cqlshmain.py:744
### SAME STACK ###
cmdloop, cqlshmain.py:728
main, cqlshmain.py:2352
<module>, cqlsh.py:88
### SAME STACK ###
and
cql_parse, cqlhandling.py:128
parse_for_select_meta, cqlshmain.py:862
perform_simple_statement, cqlshmain.py:915
perform_statement, cqlshmain.py:840
do_select, cqlshmain.py:834
handle_statement, cqlshmain.py:802
onecmd, cqlshmain.py:765
### SAME STACK ###
cmdloop, cqlshmain.py:728
main, cqlshmain.py:2352
<module>, cqlsh.py:88
### SAME STACK ###
I don't understand why we're parsing the tokens a 2nd time, since we already do
it at cqlhandling.py:136, but I'll look into this closer separately.
> Do not fail cqlsh when empty statement is parsed
> ------------------------------------------------
>
> Key: CASSANDRA-19956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19956
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
> Reporter: Stefan Miklosovic
> Assignee: Pedro Gordo
> Priority: Low
> Fix For: 5.x
>
> Attachments: cqlshlib_tests-1.txt, cqlshlib_tests.txt
>
>
> This really irritates me.
> {code:java}
> cqlsh> select * from ks.tb;;
> ... the result ...
> SyntaxException: line 1:0 no viable alternative at input ';' ([;]){code}
> The second ";" should not matter. It is same way e.g. in Java. When I do
> {code:java}
> int a = 5;;;;;;;; {code}
> This is just perfectly legal. Indeed, more than one ";" is redundant, but it
> still compiles.
> We should do same for CQL.
> {code:java}
> cqlsh> select * from ks.tb;;;;;;;;; {code}
> This should not fail.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
