[jira] [Resolved] (CASSANDRA-6270) SERIAL consistency in errors to v1 protocol driver

["Aleksey Yeschenko (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksey Yeschenko resolved CASSANDRA-6270.
------------------------------------------

    Resolution: Won't Fix

v1 native protocol is not intended to support all the Cassandra 2.0 features. (If it could, we wouldn't need v2 native protocol in the first place).

To use 2.0 CAS with native proto you should be using the v2 protocol.

> SERIAL consistency in errors to v1 protocol driver
> --------------------------------------------------
>
>                 Key: CASSANDRA-6270
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6270
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Cassandra 2.0
>            Reporter: Theo Hultberg
>            Priority: Minor
>
> I'm the author of the Ruby driver for CQL, and I got a bug report about strange errors when running on C* 2.0 and using lightweight transaction queries. The bug report can be found here: https://github.com/iconara/cql-rb/issues/53
> The client sent {{UPDATE table SET val = 42 WHERE row_id = 5 IF val = 41}} and when C* couldn't fulfill SERIAL consistency it sent an error back saying "Operation timed out - received only -1 responses".
> So far so good, but it also set the {{consistency}} field in the error response to 8, corresponding to {{SERIAL}} in v2 of the binary protocol, even if the communication with the client was over v1 of the protocol. Since my driver doesn't yet support v2 it doesn't think that 8 is a valid consistency, and fails to parse the frame.
> Is this the intended behaviour of C*, or an oversight in how that error is formulated? I could easily add {{SERIAL}} and accept it even if the communication is over v1 of the protocol, but the bigger issue is how C* handles drivers that do not speak the latest version of the protocol. People should be able to use a driver that worked correctly with C* X with C* X+1, right?
> Do drivers have to be accepting in what they receive from C* because they might get consistencies, data types, etc. that are from future versions of the protocol, or does C* guarantee that frames will conform to the protocol that the driver says it understands?



--
This message was sent by Atlassian JIRA
(v6.1#6144)