[
https://issues.apache.org/jira/browse/CASSANDRA-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14029650#comment-14029650
]
Tyler Hobbs commented on CASSANDRA-7378:
----------------------------------------
bq. 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.
I don't think that's necessarily the case. Here's how I would describe the
changes for this:
# Add a flag to QueryMessage that states that the query should be prepared (as
well as executed)
# If that flag was set, Cassandra can return a prepared query ID along with the
query results (using a flag to indicate that, of course)
The driver can keep a map of query strings to PreparedStatements. If the user
executes a query string, the driver can look in the map for a prepared
statement. If it finds a prepared statement, it can just send that in an
ExecuteMessage instead of sending the query string. (There are other issues to
watch out for with this map, but that's the simple version.)
The driver would still need to prepare queries against other nodes in the
cluster, so this doesn't totally eliminate the overhead of preparing queries,
but it does eliminate one roundtrip from the sequence of operations.
> 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)
