[
https://issues.apache.org/jira/browse/CASSANDRA-18302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700311#comment-17700311
]
David Capwell commented on CASSANDRA-18302:
-------------------------------------------
bq. Therefore, using asCQL may confuse the users
I guess my main question is how much of a concern is this? Right now when
users violate a data pattern (too large read, tombstone, etc.) we call
org.apache.cassandra.db.AbstractReadQuery#toCQLString which is yet another way
to go from internal type to CQL,
org.apache.cassandra.cql3.statements.SelectStatement#asCQL was only used before
for CoordinatorReadSizeWarnThresholdBytes and
CoordinatorReadSizeAbortThresholdBytes, and in those cases we log the CQL only
and don't send back to the user (by design, we only show the partition token);
when I did this it was more to inform the operators of what is going on so they
are more informed when talking with users, so the "exact" string was never
important.
So, that then gets to the current error messages for txn only, so if we look at
a few examples
{code}
cqlsh> BEGIN TRANSACTION SELECT * FROM system.peers; COMMIT TRANSACTION;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Normal
SELECT must specify either all primary key elements or all partition key
elements and LIMIT 1. In both cases partition key elements must be always
specified with equality operators; CQL SELECT * FROM system.peers"
cqlsh> BEGIN TRANSACTION SELECT tokens FROM system.peers; COMMIT TRANSACTION;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Normal
SELECT must specify either all primary key elements or all partition key
elements and LIMIT 1. In both cases partition key elements must be always
specified with equality operators; CQL SELECT tokens FROM system.peers"
cqlsh> BEGIN TRANSACTION SELECT * FROM system.peers WHERE tokens contains ('not
exists'); COMMIT TRANSACTION;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
execute this query as it might involve data filtering and thus may have
unpredictable performance. If you want to execute this query despite the
performance unpredictability, use ALLOW FILTERING"
-- this shows a bug with quoting
cqlsh> BEGIN TRANSACTION SELECT * FROM system.peers WHERE tokens contains ('not
exists') ALLOW FILTERING; COMMIT TRANSACTION;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Normal
SELECT must specify either all primary key elements or all partition key
elements and LIMIT 1. In both cases partition key elements must be always
specified with equality operators; CQL SELECT * FROM system.peers WHERE tokens
CONTAINS not exists"
{code}
in these examples there are some that are not 100% correct but give the main
thing users need. I do feel adding line/column to the error would help with
transactions, but the "correct" string is less of a concern I have.
This gets us to trade offs. We limit the txn string to 4k and in this case we
fail to log the CQL to users for large enough transactions, so for larger
transactions we are failing to show the CQL. We are also forced to hold this
string in the case it is prepared, but we already have the non-truncated string
(as you point out), so this causes us to double this memory which is also
defined by users, so not something we really can control and limit well (if you
have 1k prepared statements that are all truncated you have ~200mb (1k txn *
4096 bytes * 48 bytes for string object) of memory just for this case which we
hope to be rare.
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
