You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Aleksey Yeschenko (JIRA)" <ji...@apache.org> on 2014/11/14 16:26:34 UTC

[jira] [Resolved] (CASSANDRA-8319) Allow LWT DELETE with column comparison

     [ https://issues.apache.org/jira/browse/CASSANDRA-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksey Yeschenko resolved CASSANDRA-8319.
------------------------------------------
    Resolution: Invalid

Apparently this already works. Since 2.0.

> Allow LWT DELETE with column comparison
> ---------------------------------------
>
>                 Key: CASSANDRA-8319
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8319
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API, Core
>            Reporter: DOAN DuyHai
>            Priority: Minor
>             Fix For: 2.1.2
>
>
> Right now, the only way to use LWT with DELETE is to rely on the IF NOT EXISTS keyword
> There may be some scenarios where using IF column=xxx with DELETE is relevant.
>  I am preparing a hands-on with a chat application using C*. A chatroom is defined as:
> {code:sql}
> CREATE TABLE chatroom (
>     room_id uuid PRIMARY KEY,
>     name text,
>     participants list<frozen <person>> // person is an UDT representing a subset of the users table);
> {code}
>  Right now, upon removing a participant from the room, I need to:
> * count remaining participants in the room (read the participants list)
> * remove the room (the whole partition) is there isn't anyone inside
>  This is a read-before-write pattern, but even this does not prevent race conditions. Indeed, the last participant may leave the room at the same time a new one enters
>  So using LWT with "DELETE FROM chatroom IF participants = [] WHERE room_id= ..." may help making the removal safe
>  With this design, room creation/deletion as well as participants addition/removal should go through LWT to be consistent. It's slow but participant joining and leaving event frequency is low enough compared to people posting messages to make the trade off not too expensive in general



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)