[ 
https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792111#action_12792111
 ] 

Jonathan Ellis commented on CASSANDRA-336:
------------------------------------------

> It seems that the proposed Deletion in CASSANDRA-293 is including a 
> SlicePredicate (well, a binary that's called slice_predicate)

?? no, it's a "optional SlicePredicate predicate"

> only because this ticket did

The history there is that we do have people who need to remove a range of 
columns from a row (e.g. CASSANDRA-494), so that's where that requirement comes 
from.

>  Until the way slices are handled are changed deeply, it is unlikely either 
> ticket will actually use it. 

How do you mean?  293 does use it (although it doesn't push it into RowMutation 
yet -- but it needs to, for commitlog purposes).

> It also uses a binary to represent a SuperColumn

The "binary super_column" refers to the SC name, not a serialized SC object 
(the convention in our Thrift is we don't repeat the _name constantly, for 
better or worse).

See the comments on CASSANDRA-293 for why that needs to be there.


> Merge batchmutation types and support batched deletes
> -----------------------------------------------------
>
>                 Key: CASSANDRA-336
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-336
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 0.5
>            Reporter: Evan Weaver
>            Assignee: Tim Huske
>             Fix For: 0.9
>
>         Attachments: 336-thrift.patch, CASSANDRA-336-code.diff, 
> CASSANDRA-336-thrift.diff, 
> CASSANDRA-336-v2-Adding-support-for-batch-mutations.patch, 
> CASSANDRA-336-v3-Adding-support-for-batch-mutations.patch, 
> v1-0001-CASSANDRA-336.-Thrift-definition-for-batch_mutate.patch
>
>
> I need all possible mutations to be able to be bundled into a generic 
> batchMutation, and sent as one operation.
> In the absence of database constraints, this gives you all the benefits of 
> transactions with none of the implementation pain. All I care about is 
> whether a bundle of updates reaches the server atomically, mitigating issues 
> with unreliable client VMs, and allowing the client to "roll back" a set of 
> operations by merely discarding the batch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to