cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mrevilgnome <>
Subject Questions about the binary protocol spec.
Date Mon, 07 Jan 2013 07:27:54 GMT
I'm working on a C++ driver for the new binary protocol, and have one or
two items of feedback/questions regarding the spec.

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

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. Will this logic always be true? If so can we move that
logic up into the type definition so that we have a guarantee? If not then
I'll need to implement two sets of deserialization logic, one for row
results, one for everything else.

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

For those that are interested:

It's asynchronous, but I plan on also offering synchronous functionality as
well. It still needs connection pooling, retry, convenience deserialization
methods on row, and event listening. I'm also back filling documentation
and unit tests this week. I'm currently building on OSX, but it should
build on windows, linux. It's only dependencies are boost asio, and boost
system (a dep of asio). The build chain is cmake.

I plan on wrapping the library with N languages where N is defined by the
community. I'm taking requests. Also, if you have any design criticisms
come at me, I'de like to make any changes before I get much further.

Also, if someone has a preferred method of logging in C/C++ other than
callback I'm all ears.

--Matt Stump

View raw message