cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8553) Add a key-value payload for third party usage
Date Thu, 12 Mar 2015 09:23:38 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14358362#comment-14358362
] 

Robert Stupp commented on CASSANDRA-8553:
-----------------------------------------

So this is going into {{QUERY}} protocol message. There's only one bit left. I think it's
not a good idea to use that last bit when we stick to 8 bits for the flag. I see two options
here:
# Extend {{<flags>>}} in {{QUERY}} to 16 bits
# Add a second flags-byte if {{0x80}} is set in {{<flags>>}} in {{QUERY}} (so we
effectively get 7 more flags, reserving {{0x80}} in the second byte)
# Add some kind of key-value pair list for descent query parameters if {{0x80}} is set in
{{<flags>>}} in {{QUERY}}

I propose option 2 - but would like to hear other opinions/proposals on this.

What does _generic kv payload_ mean? Just passing blobs or passing a (string) key plus a typed
(serialized) value?

> Add a key-value payload for third party usage
> ---------------------------------------------
>
>                 Key: CASSANDRA-8553
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8553
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Sergio Bossa
>            Assignee: Robert Stupp
>              Labels: client-impacting, protocolv4
>             Fix For: 3.0
>
>
> An useful improvement would be to include a generic key-value payload, so that developers
implementing a custom {{QueryHandler}} could leverage that to move custom data back and forth.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message