incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <>
Subject Re: Questions about the binary protocol spec.
Date Mon, 07 Jan 2013 14:52:37 GMT
> 1. There are column types that correspond to types that are not defined by
> the spec such as Boolean, UUID, Timestamp, Decimal, Double, Float etc..
> these types always a serialized java type? What happens if Java doesn't
> define a size or byte order? Are these defined in a cassandra doc

The exact layout of those types are indeed not in the specification,
mostly out of laziness (so that might be fixed whenever "someone" takes the
time to add it). But concretely, one way to get an authoritative answer
be to look at;a=blob_plain;f=src/java/org/apache/cassandra/cql3/;hb=HEAD
to get the cql3->AbstractType correspondence and then look at the
corresponding classes in;a=tree;f=src/java/org/apache/cassandra/db/marshal
It may that there is some user-friendly doc of the layout of those type
somewhere but I'm not sure where. Though pretty much any existing client
library will have had to serialize/deserialize those same types so there's
plently of references in code form at least.

Note that for the most part, you can probably infer their definition from
description at

> 2. This is more feedback then a question: [option] is an [int][string],
> except that the string only exists if [int] is 0x00 when returning rows
> a query result.

That's not true. [option] is an [int] followed by some bytes, potentially
that depends on that first [int]. And in practice, on top of 0x00,
types (i.e. 0x020, 0x021 and 0x022) all uses the subsequent bytes and not
as a

> 3. Right now global keyspace and global table flags are not being used in
> test query results, this means that columns returned could possibly come
> multiple tables. As a result the methods on my row class need parameters
> keyspace, table, and column (cql_row_t::get_string(k, t, c)) for all
> CQL currently lacks a join so there is no reason why the global flag
> be set. Is this a bug?

There is 2 places in the spec that uses the <metadata> part described in (the one using the global table flag): a 'Rows' result set (the one
described by and that correspond to the result of a SELECT and
'Prepared' result (described in

In the first case, it is true that Cassandra not having joins, you cannot
columns from different tables and the global table flag can always be set.
you observe otherwise? And if so do you have an example? It is certainly the
intent that the server would set the global flag in that case and from a
check of the code, it's seems to be the case but but if you see otherwise
yes it could be a "bug" indeed.

For the second case, the result to a prepare, there is no guarantee at all
all columns will be in the same table (if it's a BATCH), so in that case the
global table flag may or may not be set.

Now can you have your API for resultSet assume all columns are in the same
table? All I can tell you is that it's the case today and as far as I know
there is no plan to add any form of joins any time soon.

> Also, the reference Java driver always assumes the same keyspace and
> which given that there is no join is correct, but is an incorrect
> implementation according to the spec.

What is it you call "the reference Java driver"? If it's, then no, as far as I can tell it
doesn't assume the same keyspace and table (or you'd have to be more
precise on
where you thing it assumes that because it is not the intent).


View raw message