[
https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700303#comment-17700303
]
Caleb Rackliffe edited comment on CASSANDRA-18302 at 3/14/23 4:43 PM:
----------------------------------------------------------------------
Let's look at the particular example from
{{testSetMapElementFromMapElementReference}}, assuming the one-line fix I
mentioned
[above|https://issues.apache.org/jira/browse/CASSANDRA-18302?focusedCommentId=17699878&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17699878]
is in place...
{noformat}
SELECT int_map[?] FROM distributed_test_keyspace.tbl0 WHERE k = 0
{noformat}
...becomes...
{noformat}
SELECT int_map['one'] FROM distributed_test_keyspace.tbl0 WHERE k = 0
{noformat}
The only difference here between the original query and the {{asCQL()}} output
is the value binding for {{'one'}}. Combined w/ a line number, it seems pretty
easy to see what's going on. (In this case, the only reason I think we found
the problem is that we forgot to use {{LazyToString}} in
{{createNamedReads()}}? CC [~dcapwell]) Are there other examples where the
disconnect is more problematic?
Aside from all that, the {{asCQL()}} and {{toCQLString()}} complex has been
around for a while, and the former seems like it needs the fix above
independent of Accord. It would be nice to avoid more new complexity than
necessary, but I guess what we have to hash out is how much new complexity (and
up-front, non-lazy processing) is worth having error messages w/ the _exact_
CQL strings supplied by the user.
Interested in other opinions here...
was (Author: maedhroz):
Let's look at the particular example from
{{testSetMapElementFromMapElementReference}}, assuming the one-line fix I
mentioned
[above|https://issues.apache.org/jira/browse/CASSANDRA-18302?focusedCommentId=17699878&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17699878]
is in place...
{noformat}
SELECT int_map[?] FROM distributed_test_keyspace.tbl0 WHERE k = 0
{noformat}
...becomes...
{noformat}
SELECT int_map['one'] FROM distributed_test_keyspace.tbl0 WHERE k = 0
{noformat}
The only difference here between the original query and the {{asCQL()}} output
is the value binding for {{'one'}}. Combined w/ a line number, it seems pretty
easy to see what's going on. (In this case, the only reason I think we found
the problem is that we forgot to use {{LazyToString}} in
{{createNamedReads()}}? CC [~dcapwell]) Are there other examples where the
disconnect is more problematic?
Aside from all that, the {{asCQL()}} and {{toCQLString()}} complex has been
around for a while, and the former seems like it needs the fix above
independent of Accord. It would be nice to avoid more new complexity than
necessary, but I guess what we have to hash out is how much new complexity is
worth having error messages w/ the _exact_ CQL strings supplied by the user.
Interested in other opinions here...
> Fix AIOOBE and improve validation messages for transaction statements
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-18302
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18302
> Project: Cassandra
> Issue Type: Improvement
> Components: Accord
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Currently it happens sometimes that ArrayIndexOutOfBoundsException is thrown
> from asCql method when validation transaction statement. In addition, asCql
> does not return precisely the query user entered so the whole error message
> can be misleading.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
