You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ramon Nogueira (JIRA)" <ji...@apache.org> on 2013/10/10 09:29:43 UTC

[jira] [Commented] (CASSANDRA-6147) Break timestamp ties for thrift-ers

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

Ramon Nogueira commented on CASSANDRA-6147:
-------------------------------------------

This is not really a solution that allows you to use client-generated timestamps and get row-level isolation (the real problem). Instead what you are providing is a way to opt-out of client generated timestamps altogether. But client-generated timestamps still break row-isolation, and this affects CQL too.


> Break timestamp ties for thrift-ers
> -----------------------------------
>
>                 Key: CASSANDRA-6147
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6147
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Edward Capriolo
>            Assignee: Edward Capriolo
>             Fix For: 2.1
>
>
> Thrift users are still forced to generate timestamps on the client side. Currently the way the thrift bindings are generated users are forced to supply timestamps. There are two solutions I see.
> * -1 as timestamp means "generate on the server side"
> This is a breaking change, for those using -1 as a timestamp (which should effectively be no one.
> * Prepare yourself....
> Our thrift signatures are wrong, you can't overload methods in thrift
> thrift.get(byte [], byte[], ts) 
> should REALLY be changed to 
> GetRequest g =  new GetRequest()
> g.setName()
> g.setValue()
> g.setTs() ///optional 
> thrift. get( g )
> I know no one is going to want to make this change because thrift is quasi/dead but it would allow us to evolve thrift in a meaningful way. We could simple add these new methods under different names as well.



--
This message was sent by Atlassian JIRA
(v6.1#6144)