> 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.. Will
> 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 somewhere?

The exact layout of those types are indeed not in the specification, honestly
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 would
be to look at
to get the cql3->AbstractType correspondence and then look at the corresponding classes in
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 the

> 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 from
> a query result.

That's not true. [option] is an [int] followed by some bytes, potentially none,
that depends on that first [int]. And in practice, on top of 0x00, collection
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 my
> test query results, this means that columns returned could possibly come from
> multiple tables. As a result the methods on my row class need parameters for
> keyspace, table, and column (cql_row_t::get_string(k, t, c)) for all cases,
> CQL currently lacks a join so there is no reason why the global flag wouldn't
> 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 have
columns from different tables and the global table flag can always be set. Do
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 quick
check of the code, it's seems to be the case but but if you see otherwise then
yes it could be a "bug" indeed.

For the second case, the result to a prepare, there is no guarantee at all that
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 table,
> 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
https://github.com/datastax/java-driver, 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).