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 [mailto:sylv...@datastax.com] Sent: Monday, November 19, 2012 6:25 PM To: dev@cassandra.apache.org 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. -- Sylvain
