cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Hodges (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-336) Merge batchmutation types and support batched deletes
Date Thu, 17 Dec 2009 19:52:18 GMT


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:
>             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.

View raw message