[
https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700798#comment-17700798
]
Caleb Rackliffe edited comment on CASSANDRA-18302 at 3/15/23 5:47 PM:
----------------------------------------------------------------------
So I was almost going to propose that we keep the start/end {{Token}} and
{{TokenStream}} around to _actually_ lazily create our error messages, but
that's even worse than creating and keeping around a raw string per statement.
The original motivation for the lazy evaluation was that {{asCQL()}} would be
too expensive to call on every transaction, when most of the time it wouldn't
be used anyway. With {{describe()}} the extra allocations have already
happened, so the damage is done.
At this point, unless there's a way to avoid creating strings for the raw CQL
for every statement that we won't use 99.99% of the time, I'm still essentially
in favor of doing [what I mentioned
above|https://issues.apache.org/jira/browse/CASSANDRA-18302?focusedCommentId=17700416&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17700416].
I know that doesn't go as far to help w/ normal batch statement error messages
(although they could take advantage of line numbers, which look cheap).
Perhaps later we can expand this once we've merged to trunk and the entire CQL
integration is in its final form?
was (Author: maedhroz):
So I was almost going to propose that we keep the start/end {{Token}} and
{{TokenStream}} around to _actually_ lazily create our error messages, but
that's even worse than creating and keeping around a raw string per statement.
The original motivation for the lazy evaluation was that {{asCQL()}} would be
too expensive to call on every transaction, when most of the time it wouldn't
be used anyway. With {{describe()}} the extra allocations have already
happened, so the damage is done.
At this point, unless there's a way to avoid creating strings for the raw CQL
for every statement that we won't use 99.99% of the time, I'm still essentially
in favor of doing [what I mentioned
above|https://issues.apache.org/jira/browse/CASSANDRA-18302?focusedCommentId=17700416&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17700416].
I know that doesn't go as far to help w/ normal batch statement error messages
(although they could take advantage of line numbers, which look cheap).
> 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: 2h
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
