[jira] [Commented] (CASSANDRA-7378) Protocol: Autoprepare flag for QUERY and BATCH requests

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

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

Sylvain Lebresne commented on CASSANDRA-7378:
---------------------------------------------

One of the point of prepared statements (not the only one nor even the most important one but still one of them) is that you don't have to send the query string itself for execution, thus saving some bandwidth. If we added this, a driver that wants to use that would presumably always use it for executing prepared statements and that would imply that it would always send the query string just in case the server may have to re-prepared. Imo, that's a waste and we don't want to encourage it.

Let me also note that if properly used, prepared statements should never be evicted. The only reason the server evicts prepared statements is to protect from OOMing if a client is misbehaving. But we don't want to optimize for clients that misbehave. So yes, the client drivers have to do a little bit of management of the prepared statements, but I don't think it's complicated enough that it's worth sending the query string every time when 99.9% of the time it will be useless.

> Protocol: Autoprepare flag for QUERY and BATCH requests
> -------------------------------------------------------
>
>                 Key: CASSANDRA-7378
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7378
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API
>            Reporter: Jorge Bay
>            Priority: Minor
>
> Currently the flow for executing a prepared statement in the native protocol is:
> - PREPARE request
> - prepared response (queryid)
> - EXECUTE request (using queryid)
> 	- RESULT response
> 	- or UNPREPARED error response
> As is today, it is the responsibility of the driver or client to maintain the query id and to send a EXECUTE message using this query id and to expect for UNPREPARED error response in case the query got evicted or the node was restarted.
> With the following implications:
> - Before making a EXECUTE request, there is no way to know if it got evicted.
> - Before sending a PREPARE request, there is no way to know if that query has been already prepared on that host (by another connection), .
> - There isn't anything else the client can do with the prepared id (no much use from the client perspective).
> It would be nice to have a flag in the QUERY and BATCH requests that when set, the Cassandra node will prepare (if not already prepared) and execute the prepared query. This way we could save a few extra roundtrips and make the protocol flow for prepared statements a little more simple.



--
This message was sent by Atlassian JIRA
(v6.2#6252)