cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7378) Protocol: Autoprepare flag for QUERY and BATCH requests
Date Fri, 13 Jun 2014 09:47:02 GMT

    [ 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)

Mime
View raw message