cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-2478) Custom CQL protocol/transport
Date Tue, 19 Jun 2012 15:29:43 GMT


Sylvain Lebresne updated CASSANDRA-2478:

    Attachment: cql_binary_protocol-v2

I've pushed at an updated version of this
patch. I'm also attaching the v2 document describing this new version. This version adds to
the previous one:
* keyspace and table names to the metadata returned as response to SELECT and prepared queries.
The protocol supports having different ks/cf names for each column, but have a more compact
form when all columns are from the same ks/cf (which is always the case for SELECT, but not
for prepared queries).
* it removes (mostly from the document) the few tidbits about the sketched auto-paging. I
turns out this is more complicated than I though and may require a bit more discussion. So
I prefer living that to a follow up ticket.
* a few other cleanups

In this form, this is a "complete" first version in that it is on par with the thrift API.
So imo it's a good first step and I'd like trying to get that in and then adds new features/improve
it in separate tickets (SSL, auto-paging, consider SASL, etc...). I think the sooner we get
a working version in, the sooner we'll have people playing with it and get feedback.

> Custom CQL protocol/transport
> -----------------------------
>                 Key: CASSANDRA-2478
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Eric Evans
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>              Labels: cql
>         Attachments: cql_binary_protocol, cql_binary_protocol-v2
> A custom wire protocol would give us the flexibility to optimize for our specific use-cases,
and eliminate a troublesome dependency (I'm referring to Thrift, but none of the others would
be significantly better).  Additionally, RPC is bad fit here, and we'd do better to move in
the direction of something that natively supports streaming.
> I don't think this is as daunting as it might seem initially.  Utilizing an existing
server framework like Netty, combined with some copy-and-paste of bits from other FLOSS projects
would probably get us 80% of the way there.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message