[
https://issues.apache.org/jira/browse/CASSANDRA-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-5443:
----------------------------------------
Attachment: 0004-Support-tombstones-when-comparing-for-CAS.txt
0003-Handle-deleted-and-expiring-column-in-paxos-updates.txt
0002-Add-syntax-to-support-conditional-update-delete.txt
0001-Refactor-Update-and-Delete-statement-to-extract-common.txt
Attaching patches for this. The first patch is a refactor whose goal is to make
the 2nd patch, the one that add the new bits, easier. That refactor also cleans
up those statements somewhat by better sharing code that is common. The 2nd
patch adds the following syntax:
{noformat}
UPDATE test SET v1 = 5, v2 = 'foobar', v3 = 5 WHERE k = 0 IF v1 = 3 AND v2 =
'foo';
DELETE v2 FROM test WHERE k = 0 IF v1 = 5;
{noformat}
A few remarks on that syntax:
* Despites my earlier comments, I've left off the {{ATOMICALLY}} and I admit
it's seducing to just have the {{IF}} and nothing more. That being said, I
still think that simplify has a downside, which is that it doesn't emphasis
much that an update with or without IF have very different perfomance
characteristics. But let's say I'm now leaning more towards a simpler syntax
and making sure we're clear on the performance impact in documentations.
* I've used {{AND}} to separate conditions. The other option would be to use a
comma to mimick the SET clause, but it felt a {{AND}} was sounding better after
a {{IF}}.
The 2 last patches fix small "bugs" with the paxos code itself (and can be
committed independently):
* patch 3 fixes make sure we don't correctly preserve deleted and expiring
columns in paxos updates.
* patch 4 tweaks the CAS comparison to handle correctly deleted columns in
"expected". That allows to support condition like "IF v1 = null".
Now there is a few things that don't work yet:
# updating a row if it doesn't exist yet is not supported. To be more precise,
we do handle {{null}} in conditions, but that's only good for non primary key
components. And I'm not sure allowing PK columns in conditions would be a good
solution because I'm not sure
{noformat}
UPDATE test SET v1 = 5, v2 = 'foobar' WHERE k = 0 IF k = null
{noformat}
really carries the intent very well (the {{WHERE}} and {{IF}} _sound_
contradictory). Also, the fact that
{noformat}
UPDATE test SET v1 = 5, v2 = 'foobar' WHERE k = 0 IF k = 1
{noformat}
suggests to me that it's not really the right syntax. Lastly, it would require
a bit of ugly special casing in the code (not a blocker but ...).
# the code ignores completely the consistency level so far. That part is
basically pending CASSANDRA-5442.
# the code does support sets and maps in conditions, but lists are *not*
supported (an InvalidRequestException is thrown is a list is in the
conditions). The reason is that for lists, the cell name contains a server side
generated timeuuid, and so we would need to make sure the timeuuids in the
_expected_ CF we build match the current ones. And well, that's doable but will
require some special additional code so I've left it off for now.
Last but not least, so far the code returns a resultset with one boolean column
named 'result' (so like in my comment above). We can easily change that to a
count of 0 or 1 expressing the number of affected rows as discussed above, but
as said I'm not fully convinced by that idea yet. One of the reason being that
if we do ever allow conditional updates in batches (which would be doable, at
least for UNLOGGED ones), the number of affected rows wouldn't cut it anymore.
Now, to be fair, the current 1 column resultSet wouldn't work either, but
that's why my suggestion would be to change that to return one column per
partition key (since we do CAS at that level). So for instance
{noformat}
UPDATE test SET v1 = 5, v2 = 'foobar', v3 = 5 WHERE k = 0 IF v1 = 3 AND v2 =
'foo';
{noformat}
would return the following result set:
{noformat}
upd(k = 0)
----------
true
{noformat}
so basically the same thing that with the attached patch except that the column
result would indicate the value of the partition key updated, which would work
if we do add batches (the one downside being that if people starts to use large
blobs as partition keys it'll get messy, but not sure that's a big concern).
Opinions?
> Add CAS CQL support
> -------------------
>
> Key: CASSANDRA-5443
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5443
> Project: Cassandra
> Issue Type: Sub-task
> Components: API, Core
> Reporter: Jonathan Ellis
> Assignee: Sylvain Lebresne
> Fix For: 2.0
>
> Attachments:
> 0001-Refactor-Update-and-Delete-statement-to-extract-common.txt,
> 0002-Add-syntax-to-support-conditional-update-delete.txt,
> 0003-Handle-deleted-and-expiring-column-in-paxos-updates.txt,
> 0004-Support-tombstones-when-comparing-for-CAS.txt
>
>
--
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
