[ 
https://issues.apache.org/jira/browse/CASSANDRA-21139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18055306#comment-18055306
 ] 

Bret McGuire commented on CASSANDRA-21139:
------------------------------------------

+1 to the idea generally, but I'm wondering if we might be able to go even one 
better and find a way to communicate the violation of these guardrails back to 
the client as well.  Such a mechanism wouldn't just apply here... it could 
potentially apply to _all_ (or perhaps just most?) of the defined guardrails.

> 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
>
> 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]

Reply via email to