cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Reopened] (CASSANDRA-5619) CAS UPDATE for a lost race: save round trip by returning column values
Date Thu, 04 Jul 2013 14:49:50 GMT


Sylvain Lebresne reopened CASSANDRA-5619:

I think I'm having a problem getting that issue right. This is now CQL3 that is kind of broken.
More precisely, if you do:
UPDATE foo SET v=3 WHERE k=0 IF v=2
and there is no row at all for k=0, then CQL3 currently returns an empty result set. The intention
was that it should return a result with {{v=null}} in it but:
# it's not the case so I'd need to fix it
# I realized that this was not totally ideal because returning {{v=null}} would somewhat suggest
that the row exist but v is null, while the row doesn't exist.

So not sure what's the best course of action here. Do we consider that it's ok not being able
to distinguish between "the row exists but the value of the column in the condition is null"
and "the row doesn't exist" in that specific case (in which case we still need to fix it to
return null as said above), or do we add back a "result" boolean column to tell us if the
statement applied?
> CAS UPDATE for a lost race: save round trip by returning column values
> ----------------------------------------------------------------------
>                 Key: CASSANDRA-5619
>                 URL:
>             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: 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]

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:

View raw message