cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-5443) Add CAS CQL support
Date Fri, 26 Apr 2013 14:40:16 GMT

     [ 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

Mime
View raw message