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

Sylvain Lebresne commented on CASSANDRA-5619:
---------------------------------------------

bq. The problem with adding a column to the resultset is that it can conflict 
with a user-defined column of the same name

I agree. Though for the record I'll note that we already have that problem in 
another context. Namely, when you prepare a timestamp or a ttl, in the metadata 
returned, we use [timestamp] and [ttl] for the name of the prepared variables 
returned (since CQL does return the column names for the prepared variables in 
that case), which can conflict in theory with existing column names. So anyway, 
not saying this is something we should do too often, but just wanted to mention 
it.

bq. an exception for failure at the protocol level

I can live with that, I'll rework the patch that way. Do you want to change it 
on the thrift side (I'd rather not bother personally since as you said earlier, 
nobody uses raw thrift anyway, but I'm fine changing it if that's you 
preference).
                
> CAS UPDATE for a lost race: save round trip by returning column values
> ----------------------------------------------------------------------
>
>                 Key: CASSANDRA-5619
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5619
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 2.0 beta 1
>            Reporter: Blair Zajac
>            Assignee: Sylvain Lebresne
>             Fix For: 2.0 beta 1
>
>         Attachments: 0001-Add-back-boolean-result-column.txt, 
> 5619_thrift_fixup.txt, 5619.txt
>
>
> Looking at the new CAS CQL3 support examples [1], if one lost a race for an 
> UPDATE, to save a round trip to get the current values to decide if you need 
> to perform your work, could the columns that were used in the IF clause also 
> be returned to the caller?  Maybe the columns values as part of the SET part 
> could also be returned.
> I don't know if this is generally useful though.
> In the case of creating a new user account with a given username which is the 
> partition key, if one lost the race to another person creating an account 
> with the same username, it doesn't matter to the loser what the column values 
> are, just that they lost.
> I'm new to Cassandra, so maybe there's other use cases, such as doing 
> incremental amount of work on a row.  In pure Java projects I've done while 
> loops around AtomicReference.html#compareAndSet() until the work was done on 
> the referenced object to handle multiple threads each making forward progress 
> in updating the references object.
> [1] https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to