[
https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701376#comment-13701376
]
Jonathan Ellis commented on CASSANDRA-5619:
-------------------------------------------
bq. in the metadata returned, we use [timestamp] and [ttl] for the name of the
prepared variables returned
Could we do {{timestamp(column)}} and {{ttl(column)}}, including literal
parentheses, where {{column}} is the name of the column involved? These would
not be legal column names so we would be safe from conflicts.
Could do something similar here -- pick a not-quite-legal column name -- but I
do think the exception approach is cleaner, despite returning a resultset in
the exception.
If we're doing CasFailedExceptions in StorageProxy I do think it's cleanest to
continue to translate it into a Thrift-side exception the way we do with
WriteTimeout et al. No?
> 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
