[
https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792078#action_12792078
]
Jonathan Ellis commented on CASSANDRA-336:
------------------------------------------
the approach looks good in general and the refactoring was well done. (but
please, don't break lines when they are nowhere near our convention of 120
columns! :)
one thing that needs to be fixed is, the Deletion struct here and in
CASSANDRA-293 (which just got a patch) need to be the same. If we have two
different ones I guarantee one will need to be deprecated in the future, so
let's save ourselves that trouble. And, since 293 adds support for range
deletes to RowMutation, supporting that too should be pretty easy.
> 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.
