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

Edward Capriolo commented on CASSANDRA-6147:
--------------------------------------------

In java land
{code}
void remove(1:required binary key,
2:required ColumnPath column_path,
3:required i64 timestamp,
4:ConsistencyLevel consistency_level=ConsistencyLevel.ONE)
{code}

compiles into a method 
{code}
    public void remove(ByteBuffer key, ColumnPath column_path, long timestamp, 
ConsistencyLevel consistency_level)
    throws InvalidRequestException, UnavailableException, TimedOutException
{code}

So this timestamp can't "optional". Batch mutate will benefit however and other 
languages outside of java might.

> Allow Thrift opt-in to server-side timestamps
> ---------------------------------------------
>
>                 Key: CASSANDRA-6147
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6147
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: API
>            Reporter: Edward Capriolo
>            Assignee: Edward Capriolo
>            Priority: Minor
>             Fix For: 2.1 beta2
>
>
> 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.2#6252)

Reply via email to