cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "paul cannon (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4539) potential backwards incompatibility in native protocol
Date Tue, 14 Aug 2012 22:43:38 GMT


paul cannon commented on CASSANDRA-4539:

Another potential problem is if a client program wants to use a STARTUP option not yet understood
by the driver. If an option's value part is always a {{[value]}}, then the driver doesn't
have to guess how to send that argument to the server.

(It might also be worthwhile to make the values in STARTUP optionlists always be {{[string]}}
s, so that apps don't have to bother with potentially encoding binary values themselves when
the driver doesn't recognize those options.)
> potential backwards incompatibility in native protocol
> ------------------------------------------------------
>                 Key: CASSANDRA-4539
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 1.2
>            Reporter: paul cannon
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>              Labels: cql, native_protocol
>             Fix For: 1.2
> In the text of the native_protocol.spec document, it explains the format for a notation
called {{[option]}}, which should represent "{{a pair of <id><value>}}".
> In doing a first-draft implementation of the protocol for the python driver, though,
I found that I had a misunderstanding. I read that section as saying that {{<value>}}
was a {{[value]}}, and that it could have a length of 0 (i.e., the {{[int]}} on the front
of the {{[value]}} could be 0). However, it turns out that {{<value>}} might not be
there at all, or might be *two* {{[value]}}'s, depending on the option id and message context.
> I'm not a fan of this, since
>  * A protocol parsing library can't simply implement a single function to read in {{[option]}}'s,
since the length of the value part is dependent on the message context
>  * If we add a new native data type (a new option id which could be used inside a {{<col_spec_i>}}
in a RESULT message), then older clients will not know how to read past the value part. Of
course they won't know how to interpret the data or deserialize later rows of that unknown
type - that's not the problem - the problem is that the older client should be able just to
mark that column as unparseable and still handle the rest of the columns.
> Can we make {{<value>}} be a {{[value]}}, the contents of which can be re-interpreted
as a {{[string]}}, an {{[option]}}, two {{[option]}}'s, or whatever?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message