paul cannon created CASSANDRA-4539:
--------------------------------------

             Summary: 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
             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

        

Reply via email to