incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre Chalamet" <>
Subject RE: Questions on cql binary protocol
Date Fri, 23 Nov 2012 19:47:35 GMT
Thanks Sylvain for explaining motivation behind this. Quite understandable.
All in all, that's not a big deal anyway and can be easily overcome.

- Pierre

-----Original Message-----
From: Sylvain Lebresne [] 
Sent: Monday, November 19, 2012 6:25 PM
Subject: Re: Questions on cql binary protocol

> Could you confirm that query id is server scoped ? (meaning can I 
> disconnect and reconnect later using the same request Id).

It is. I've pushed a sentence in the doc to clarify that point.

> .        Having TTL and TIMESTAMP after [consistency] in the QUERY frame
> would be helpful for client libraries - otherwise CQL parsing is required
> to
> modify/append this info. I don't see why this could not be done like
> [consistency] - it's purely technical and could get out of the way of the
> CQL body query.

The reason we've moved the consistency is that we believe the consistency
belongs to the protocol rather than the language, as it influences how the
query executes but not what it does fundamentally. It is not true of either
the ttl or the timestamp that both change what is inserted by the query.
For that reason, they both belong to the language, not the protocol. And we
don't want to allow overriding language stuffs from the protocol because
it's messy and complicate things.

Now I don't think this is really useful either, in the sense that yes, you
cannot append/modify it without parsing the query, but it's not different
for any other part of the query. You can't either modify the where clause
of a select query without parsing it. There is 2 cases in my opinion:
either you write a low level API that takes CQL3 string directly, and in
that case it shouldn't be your role to modify/append the ttl/timestamp, or
you have an higher level API that generates queries under the hood and it's
not a problem at all.

> .        RESULT supports global_table_spec but QUERY/RESULT do not. This
> would be nice to have such support there to help "relocating" a query to
> another keyspace easily without having to deal with CQL parsing. Obviously
> that's why USE exists, but this implies a keyspace tracking per connection
> and this can easily defeats connections pool (and if not, this involves a
> USE statement to force a keyspace change).

It is relatively clear that it's hard to do otherwise than having one
pool-per keyspace on the client side. On the other side, this has also been
the case for thrift for ages and I don't think this has been a big pain
point for people. And if only, CQL is more flexible in that front since
users can always prefix their table with the keyspace name to bypass
whatever current keyspace is set. So I'd say that its a bit of the same
thing than above: if you expose query strings directly, then yes you'll
have to stick to one keyspace per connection pool, but experience shows
that it's not a real problem. And if you expose an higher level API, then
you can always use the keyspace name in the generated query and in that
case you don't even have the one-keyspace-per-pool limitation.


View raw message