[
https://issues.apache.org/jira/browse/CASSANDRA-21139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18073420#comment-18073420
]
Rishabh Saraswat commented on CASSANDRA-21139:
----------------------------------------------
Here's a summary of changes
* Excludes insert statements from check - [Insert's grammar
|[https://github.com/apache/cassandra/blob/trunk/doc%2Fcql3%2FCQL.textile],
|https://github.com/apache/cassandra/blob/trunk/doc%2Fcql3%2FCQL.textile],]<insertStatement>
::= INSERT INTO <tablename>
( ( <name-list> VALUES <value-list> )
| ( JSON <string> (DEFAULT ( NULL | UNSET ))?))
( IF NOT EXISTS )?
( USING <option> ( AND <option> )* )?
no WHERE clause
* insert statements can't have where blocks, so excluded them as they are an
instance of ModificationStatement same as update and delete statementa.
* Warning statements will include keyspace and table name to trace to mis
prepared query easy.
* As parameter was renamed, changed the semantics of docs too.
> Guardrail for miss-prepared statements
> --------------------------------------
>
> Key: CASSANDRA-21139
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21139
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
> Reporter: Brad Schoening
> Assignee: Rishabh Saraswat
> Priority: Normal
> Fix For: 6.x
>
> Attachments: Positive Failure.png, Server Side Logging.png, script.txt
>
> Time Spent: 12h
> Remaining Estimate: 0h
>
> We have hundreds of application teams and several dozen of them miss-prepare
> statements by using literals instead of bind markers.
> I.e.,
> {code:sql}
> // wrong
> session.prepare("select * from users where ID = 996");
> session.prepare("select * from users where ID = 997");
> session.prepare("select * from users where ID = 998");
> session.prepare("select * from users where ID = 999");
> // correct
> session.prepare("select * from users where ID = ?");
> {code}
> The problem causes the prepared statement cache to constantly overflow, and
> will print a prepared statements discarded WARN message in the Cassandra log.
> At present, we use a wack-a-mole approach to discuss the problem with each
> development team individually, and hope they fix it and train the entire team
> on how to prepare statements correctly.
> Also, finding the root cause of the issue today requires having the knowledge
> and access to look at the system.prepared_statements table.
> Guardrails would seem a good approach here, where the guard could WARN or
> REJECT when a statement was prepared using a WHERE clause and no bind markers.
> Note, this should not prevent users from creating prepared statements without
> a WHERE clause or with one or more literal values so long as there was at
> least one bind marker. Thus, the following would remain valid:
> {code:sql}
> session.prepare("select * from users");
> session.prepare("select * from users where TYPE=5 and ID = ?");
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
