[
https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792103#action_12792103
]
Jeff Hodges 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) only because this
ticket did. Until the way slices are handled are changed deeply, it is unlikely
either ticket will actually use it.
It also uses a binary to represent a SuperColumn, but if find it unlikely that
we would want that, either. Would it make more sense to make that Deletion like
this one instead?
> 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,
> 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.
