[
https://issues.apache.org/jira/browse/CASSANDRA-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701868#comment-13701868
]
Sylvain Lebresne commented on CASSANDRA-5619:
---------------------------------------------
bq. Could we do timestamp(column) and ttl(column), including literal
parentheses, where column is the name of the column involved?
In the case I'm talking about, there isn't a specific column involved (or
rather there could be more than one). The one I'm talking about is
if you do:
{noformat}
UPDATE foo USING TTL ? SET c1=2, c2=3, ....
{noformat}
In that case the TTL applies to all the columns. And so in that case we
currently return [ttl] (with the square bracket btw) as name for the first
prepared marked.
bq. These would not be legal column names
Actually, they would. Provided you double quote a column name, we're pretty
permissive about what it can be: it can be anything really, and "timestamp()"
is as much legal than "[timestamp]".
This does is a problem somewhat, don't get me wrong. Even ignoring the
timestamp/ttl in prepared statements, if you do:
{noformat}
SELECT "writeTime(c)", writeTime(c) FROM foo;
{noformat}
we'll return a resultSet where both "column" with the string "writeTime(c)" as
identifier, and the only way to distinguish between the arguably weird column
name and the function call is by position in the result set.
But so far we've somewhat dodged that issue saying that you really have to be
looking for trouble to run into this, and that you still can rely on positions
in the result set anyway. We could probably disambiguate this, though so far
I've wondered if it was worth the trouble really.
Anyway, that's somewhat unrelated to this issue but wanted to be complete.
> 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
