cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandeep Tamhankar (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10145) Change protocol to allow sending key space independent of query string
Date Tue, 15 Nov 2016 22:42:58 GMT


Sandeep Tamhankar commented on CASSANDRA-10145:

I'll address these questions tomorrow, but your response reminded me of another question I
forgot to ask:

The flags field was changed from 1-byte to int (4-byte) sometime recently because we'd saturated
the current flags byte. Was there any consideration to making 0x80 mean "extended-flags" and
introduce one "extended-flags" byte in the message if 0x80 is set in the primary flags byte?
I imagine we don't add new optional args in messages that often, so having one extra byte
would suit the protocol for quite some time and only use 1 extra byte in messages. We reduce
"flag storage efficiency" by 1/8 since 0x80 in every flags byte is just an indicator that
there is another flags byte we need to parse (somewhere later in the message). And we use
2 less bytes in every request (current 4-byte int vs. my proposed 2 byte scheme) for years
to come.

> Change protocol to allow sending key space independent of query string
> ----------------------------------------------------------------------
>                 Key: CASSANDRA-10145
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Vishy Kasar
>            Assignee: Sandeep Tamhankar
>             Fix For: 3.x
>         Attachments: 10145-trunk.txt
> Currently keyspace is either embedded in the query string or set through "use keyspace"
on a connection by client driver. 
> There are practical use cases where client user has query and keyspace independently.
In order for that scenario to work, they will have to create one client session per keyspace
or have to resort to some string replace hackery.
> It will be nice if protocol allowed sending keyspace separately from the query. 

This message was sent by Atlassian JIRA

View raw message