Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 13 Jun 2014 07:56:02 +0000 (UTC)
From: "Jorge Bay (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12720569.1402490067868.125226.1402646162247@arcas>
In-Reply-To: <JIRA.12720569.1402490067868@arcas>
References: <JIRA.12720569.1402490067868@arcas>
Subject: [jira] [Commented] (CASSANDRA-7378) Protocol: Autoprepare flag for
 QUERY and BATCH requests
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jorge Bay commented on CASSANDRA-7378:
--------------------------------------

My main concern is to lower the complexity from the user perspective, but it is true that it would add a few bytes extra (there are still 16 bytes from the md5) per request, if implemented as I proposed.
If implemented as Tyler proposes, it will save bandwidth and roundtrips but it will still require some "state management" by the driver.

About preparing statements at app startup, it is a possibility but again it adds complexity to the user, forcing the user to store the prepared statement result (id) at a global scope...

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