[ https://issues.apache.org/jira/browse/CASSANDRA-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434599#comment-13434599 ]
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: https://issues.apache.org/jira/browse/CASSANDRA-4539 > 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira