[
https://issues.apache.org/jira/browse/CASSANDRA-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14029720#comment-14029720
]
Sylvain Lebresne commented on CASSANDRA-7378:
---------------------------------------------
bq. I don't think that's necessarily the case.
I was basing my comment on what was expressed as motivation for this, but it is
true that this could allow to save the round-trip. That said, I really don't
think the benefit of that is worth the complexity. In most case, it makes sense
for an application to prepare statements first at the application startup imo
rather that paying the preparation price during the first query execution.
Besides, I can't really imagine saving that one round-trip making a meaningful
difference in practice. So frankly, I'd rather not bother adding the complexity.
> 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)
