cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-8319) Allow LWT DELETE with column comparison
Date Fri, 14 Nov 2014 15:05:34 GMT

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

Jonathan Ellis updated CASSANDRA-8319:
--------------------------------------
    Summary: Allow LWT DELETE with column comparison  (was: Allow CAS DELETE with column comparison)

> 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)

Mime
View raw message