cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From paul cannon <>
Subject Re: Best place to discuss CQL Binary Protcol spec?
Date Mon, 18 Feb 2013 22:27:01 GMT
I can't usefully speak to your other questions, but the answers to the
technical questions are below.

On Mon, Feb 18, 2013 at 1:16 PM, Michael Alan Dorman <> wrote:

> * 4.1.2. CREDENTIALS
> My quick clarification is from this bit of text:
>   The body is a list of key/value informations. It is a [short] n,
>   followed by n pair of [string].  These key/value pairs [...]
> Is this just a string map, and the text just isn't using consistent
> terminology?

It has the same structure as a string map, but might not necessarily *be* a
string map. I would guess that this phrasing is used because it may be
possible to have multiple identical "keys" in this structure, which would
not make sense in a [string map]. (Although I don't think it's explicitly
stated, it seems safe to imply that [string map] is intended to be a plain
lookup table, not a set of arbitrary pairs.)

* Rows
> My more involved question is about this text describing the column
> contents:
>   - <rows_content> is composed of <row_1>...<row_m> where m is
> <rows_count>.
>     Each <row_i> is composed of <value_1>...<value_n> where n is
>     <columns_count> and where <value_j> is a [bytes] representing the value
>     returned for the jth column of the ith row. In other words,
> <rows_content>
>     is composed of (<rows_count> * <columns_count>) [bytes].
> I read this and thought, "Oh, sure I'll need to figure out the width of
> the java types for the different columns, tedious but easily doable",
> and then noticed some of the options are things like Blob or Varchar,
> both which I would assume to be variable width.  So how should one
> determine how many bytes to read for different types?

As the doc says, each <value_j> is a [bytes], which means it's represented
on the wire as an [int] x followed by x bytes.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message