incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <sylv...@datastax.com>
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..
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

https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=src/java/org/apache/cassandra/cql3/ParsedType.java;hb=HEAD
to get the cql3->AbstractType correspondence and then look at the
corresponding classes in

https://git-wip-us.apache.org/repos/asf?p=cassandra.git;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
the
description at http://cassandra.apache.org/doc/cql3/CQL.html#types.

> 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
[string].

> 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
4.2.5.2 (the one using the global table flag): a 'Rows' result set (the one
described by 4.2.5.2) and that correspond to the result of a SELECT and
'Prepared' result (described in 4.2.5.4).

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).

--
Sylvain

Mime
View raw message