[ https://issues.apache.org/jira/browse/CASSANDRA-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14030430#comment-14030430 ]
Robert Stupp commented on CASSANDRA-7378: ----------------------------------------- It sound very simple - but in fact it isn't. The Java driver for example holds a Map of _pstmt id_ to _pstmt_. The pstmt itself consists of the fields {{query}}, {{queryKeyspace}}, {{routingKey}}, {{consistency}}, {{serialConsistency}}, {{traceQuery}}, {{retryPolicy}}. These fields make the prepared statement unique. If only one field changes, it is _another_ pstmt. imo it cannot be the protocol's or driver's responsibility to optimize for this (compare with JDBC drivers - they don't do that either). And you should not make any assumptions how the _pstmt id_ is calculated - the algorithm may change due to C* internals. > 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)