You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Evan Weaver (JIRA)" <ji...@apache.org> on 2009/08/03 18:15:14 UTC
[jira] Created: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Merge batchmutation types and support batched deletes
-----------------------------------------------------
Key: CASSANDRA-336
URL: https://issues.apache.org/jira/browse/CASSANDRA-336
Project: Cassandra
Issue Type: Improvement
Reporter: Evan Weaver
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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738478#action_12738478 ]
Jonathan Ellis commented on CASSANDRA-336:
------------------------------------------
> I'm just trying to make the system more generally reliable in the presence of extremely unreliable clients
Okay, just wanted to make sure we're on the same page before you started writing a patch. :)
> The write-to-commitlog would have to be atomic ... I can see how this'd be useful
Right, for "real" atomicity that's what you'd need. I'm definitely not arguing that it wouldn't be useful, only that the scope is large enough that it's not an 0.4 task.
> Merge batchmutation types and support batched deletes
> -----------------------------------------------------
>
> Key: CASSANDRA-336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-336
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Evan Weaver
>
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evan Weaver updated CASSANDRA-336:
----------------------------------
Attachment: (was: CASSANDRA-336-deletes-in-BatchMutation-2-code.diff)
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738461#action_12738461 ]
Jonathan Ellis commented on CASSANDRA-336:
------------------------------------------
really?
because what can happen is, say you do an batch insert with multiple keys and block_for=1, but the server goes down mid-write-to-commitlog. so the client gets back a failure or a broken conn (depending on whether the client had a direct conn to the write target) but when the server comes back up and replays the log you get part of the update committed.
if all your writes are idempotent it doesn't matter, but if all your writes are idempotent i don't see why you care about atomicity. :)
> Merge batchmutation types and support batched deletes
> -----------------------------------------------------
>
> Key: CASSANDRA-336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-336
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Evan Weaver
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Ryan King (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767424#action_12767424 ]
Ryan King commented on CASSANDRA-336:
-------------------------------------
Sounds good to me. I'll continue on.
> 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: Evan Weaver
> Fix For: 0.5
>
> Attachments: 336-thrift.patch, CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff, 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759837#action_12759837 ]
Jonathan Ellis commented on CASSANDRA-336:
------------------------------------------
yes, 70 is in 0.4 and trunk
> 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: Evan Weaver
> Fix For: 0.5
>
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748453#action_12748453 ]
Jonathan Ellis commented on CASSANDRA-336:
------------------------------------------
+ for(RowMutation row_mutation : row_mutations)
+ {
+ doInsert(consistency_level, row_mutation);
}
this isn't what you want; you want to have StorageProxy dispatch the inserts in parallel so you don't have N times the latency when you operate on N keys. goffinet's patches in CASSANDRA-70 (to be merged RSN as soon as I get my thrift crap working) illustrate this approach.
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-336:
-------------------------------------
Fix Version/s: (was: 0.5)
> 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: Evan Weaver
> Attachments: 336-thrift.patch, CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff, 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evan Weaver updated CASSANDRA-336:
----------------------------------
Attachment: CASSANDRA-336-thrift.diff
CASSANDRA-336-code.diff
Rebase until I do it the real way.
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Assigned: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evan Weaver reassigned CASSANDRA-336:
-------------------------------------
Assignee: Evan Weaver
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747723#action_12747723 ]
Evan Weaver commented on CASSANDRA-336:
---------------------------------------
reviewable
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evan Weaver updated CASSANDRA-336:
----------------------------------
Attachment: CASSANDRA-336-deletes-in-BatchMutation-2-code.diff
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-deletes-in-BatchMutation-2-code.diff
>
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792837#action_12792837 ]
Hudson commented on CASSANDRA-336:
----------------------------------
Integrated in Cassandra #297 (See [http://hudson.zones.apache.org/hudson/job/Cassandra/297/])
add batch_mutate command. patch by Jeff Hodges; reviewed by jbellis for
> 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
> Reporter: Evan Weaver
> Assignee: Jeff Hodges
> 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, CASSANDRA-336-v4-Adding-support-for-batch-mutations.patch, CASSANDRA-336-v5-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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738477#action_12738477 ]
Evan Weaver commented on CASSANDRA-336:
---------------------------------------
Secondary index is the exact case I am currently worried about, but it will be useful in many places. The usability benefit is nice, because you to can queue up a bunch of crap and then decide whether you really want to send it at the end based on domain validations.
> Merge batchmutation types and support batched deletes
> -----------------------------------------------------
>
> Key: CASSANDRA-336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-336
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Evan Weaver
>
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evan Weaver updated CASSANDRA-336:
----------------------------------
Attachment: (was: CASSANDRA-336-thrift.diff)
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Sandeep Tata (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743337#action_12743337 ]
Sandeep Tata commented on CASSANDRA-336:
----------------------------------------
Evan -- are you guys planning to work on this at Twitter?
> 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
> Reporter: Evan Weaver
>
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evan Weaver updated CASSANDRA-336:
----------------------------------
Attachment: CASSANDRA-336-thrift.diff
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jeff Hodges (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Hodges updated CASSANDRA-336:
----------------------------------
Attachment: CASSANDRA-336-v2-Adding-support-for-batch-mutations.patch
This batch adds support for batched mutations.
This change includes an addition of Deletion, Mutation and batch_mutate to the thrift-generated API. It allows for the insertion or deletion of specific columns or supercolumns over multiple keys and multiple keyspaces.
It does not support slices as they turned out to be a total PITA. We would have had to make changes to the way slices were handled down to the ColumnFamily level.
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jeff Hodges (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Hodges updated CASSANDRA-336:
----------------------------------
Attachment: CASSANDRA-336-v5-Adding-support-for-batch-mutations.patch
Made insertBlocking use mutateBlocking. FIxed the accidental replacement of CL.ZERO with CL.ONE in the system tests.
> 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, CASSANDRA-336-v4-Adding-support-for-batch-mutations.patch, CASSANDRA-336-v5-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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748485#action_12748485 ]
Evan Weaver commented on CASSANDRA-336:
---------------------------------------
I agree with that, but I didn't know what the best alternative is. Do I need to make a new Thrift struct?
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-336:
-------------------------------------
Attachment: 336-thrift.patch
Looks pretty good. I made a couple changes:
- use SlicePredicate in Deletion. this still allows single columns (through a column_names list of length one) while also allowing ranges or multiple columns
- r/m `mutate`; add `remove_slice`: the latter is more useful for people using Thrift directly rather than just as a foundation for a higher-level client
Sound okay?
> 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: Evan Weaver
> Fix For: 0.5
>
> Attachments: 336-thrift.patch, CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff, 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jeff Hodges (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evan Weaver updated CASSANDRA-336:
----------------------------------
Attachment: CASSANDRA-336-code.diff
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748484#action_12748484 ]
Jonathan Ellis commented on CASSANDRA-336:
------------------------------------------
also, adding optional timestamp to ColumnPath is inconsistent with how we use thrift structs. we want to make it hard to do The Wrong Thing, and we want to not scatter data around different structs. Path is used in gets, so don't add fields that only apply to inserts to it. And Path implies a series of names, while [meta]data like timestamp goes in Column/SuperColumn.
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Assigned: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis reassigned CASSANDRA-336:
----------------------------------------
Assignee: (was: Evan Weaver)
un-assigning so people know it's up for grabs if anyone wants to take a stab at it :)
(Ryan also said it's on the back burner a few days ago)
> 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
> Fix For: 0.9
>
> Attachments: 336-thrift.patch, CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff, 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-336:
-------------------------------------
Fix Version/s: 0.9
> 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: Evan Weaver
> Fix For: 0.9
>
> Attachments: 336-thrift.patch, CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff, 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738417#action_12738417 ]
Jonathan Ellis commented on CASSANDRA-336:
------------------------------------------
the user-level API can be done by adding a ColumnOrSuperColumn type as in CASSANDRA-329 to allow a single unified batch op.
> All I care about is whether a bundle of updates reaches the server atomically
remember atomicity is per row/CF. if that is what you mean, great. otherwise you are talking about fairly involved changes to CommitLog.
> Merge batchmutation types and support batched deletes
> -----------------------------------------------------
>
> Key: CASSANDRA-336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-336
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Evan Weaver
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747534#action_12747534 ]
Evan Weaver commented on CASSANDRA-336:
---------------------------------------
Working on it now.
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
>
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Ryan King (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan King updated CASSANDRA-336:
--------------------------------
Attachment: v1-0001-CASSANDRA-336.-Thrift-definition-for-batch_mutate.patch
> 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: Evan Weaver
> Fix For: 0.5
>
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff, 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Michael Greene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Greene updated CASSANDRA-336:
-------------------------------------
Component/s: Core
> 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
> Reporter: Evan Weaver
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jeff Hodges (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759831#action_12759831 ]
Jeff Hodges commented on CASSANDRA-336:
---------------------------------------
Ah, using the CASSANDRA-70 method? How nice that it's commited now, if that's the case.
> 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: Evan Weaver
> Fix For: 0.5
>
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738470#action_12738470 ]
Evan Weaver commented on CASSANDRA-336:
---------------------------------------
Really!
I care about request atomicity, because if my client goes away, I have no way to replay the remainder of the request series, regardless of what the operations were. The writes are individually idempotent, but I still have to know what they are, because they can't be reconstructed in a new request.
Better in that case if nothing was applied at all, so I want to fire either a bundle or nothing to the server. I'll trust that the server makes a best effort to apply the batch once received, and not worry too much about failure conditions.
I'm not trying to guarantee some kind of robust atomicity; I'm just trying to make the system more generally reliable in the presence of extremely unreliable clients which could fail within a series of sequential related writes.
> Merge batchmutation types and support batched deletes
> -----------------------------------------------------
>
> Key: CASSANDRA-336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-336
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Evan Weaver
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792603#action_12792603 ]
Jonathan Ellis commented on CASSANDRA-336:
------------------------------------------
also, the inserts with CL.ZERO in the system tests were there on purpose to use the nonblocking code path, please leave those alone :)
> 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, CASSANDRA-336-v4-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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738457#action_12738457 ]
Evan Weaver commented on CASSANDRA-336:
---------------------------------------
I'm just interested in the atomicity of the request itself. The server can apply it however it pleases.
> Merge batchmutation types and support batched deletes
> -----------------------------------------------------
>
> Key: CASSANDRA-336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-336
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Evan Weaver
>
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Chris Goffinet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Goffinet updated CASSANDRA-336:
-------------------------------------
Fix Version/s: 0.5
Affects Version/s: 0.5
> 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: Evan Weaver
> Fix For: 0.5
>
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jeff Hodges (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759829#action_12759829 ]
Jeff Hodges commented on CASSANDRA-336:
---------------------------------------
What's the real way?
> 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: Evan Weaver
> Fix For: 0.5
>
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evan Weaver updated CASSANDRA-336:
----------------------------------
Attachment: (was: CASSANDRA-336-code.diff)
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Sandeep Tata (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738476#action_12738476 ]
Sandeep Tata commented on CASSANDRA-336:
----------------------------------------
The write-to-commitlog would have to be atomic (ie, a single log record) for the batchMutation
You can always ignore/stop at a malformed commitlog record during replay.
I can see how this'd be useful if you were trying to implement a secondary index.
> Merge batchmutation types and support batched deletes
> -----------------------------------------------------
>
> Key: CASSANDRA-336
> URL: https://issues.apache.org/jira/browse/CASSANDRA-336
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Evan Weaver
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Gary Dusbabek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792112#action_12792112 ]
Gary Dusbabek commented on CASSANDRA-336:
-----------------------------------------
in CASSANDRA-293 I ended up going with this:
struct Deletion {
1: required i64 timestamp,
2: optional binary super_column,
3: optional SlicePredicate predicate,
}
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743383#action_12743383 ]
Evan Weaver commented on CASSANDRA-336:
---------------------------------------
Not really...too many other things on our plate. Feel free to take it over!
> 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
> Reporter: Evan Weaver
>
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-336:
-------------------------------------
Affects Version/s: (was: 0.5)
> 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
> Reporter: Evan Weaver
> Assignee: Jeff Hodges
> 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, CASSANDRA-336-v4-Adding-support-for-batch-mutations.patch, CASSANDRA-336-v5-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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evan Weaver updated CASSANDRA-336:
----------------------------------
Attachment: CASSANDRA-336-deletes-in-BatchMutation.diff
1st pass of 1st step
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-deletes-in-BatchMutation.diff
>
>
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792602#action_12792602 ]
Jonathan Ellis commented on CASSANDRA-336:
------------------------------------------
is mutateBlocking sufficiently less efficient than insertBlocking that we need to keep the latter around, too? seems to me like it shouldn't be.
> 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, CASSANDRA-336-v4-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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jeff Hodges (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Hodges updated CASSANDRA-336:
----------------------------------
Attachment: CASSANDRA-336-v4-Adding-support-for-batch-mutations.patch
Updated Deletion to accept SlicePredicates. However, since the underlying Cassandra does not yet work correctly with SliceRanges using them marks the Deletion as invalid.
This can be fixed when CASSANDRA-293 goes in.
> 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, CASSANDRA-336-v4-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.
[jira] Assigned: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Tim Huske (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Huske reassigned CASSANDRA-336:
-----------------------------------
Assignee: Tim Huske
> 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, 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evan Weaver updated CASSANDRA-336:
----------------------------------
Attachment: (was: CASSANDRA-336-deletes-in-BatchMutation-2-gen-java.diff)
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-code.diff, CASSANDRA-336-thrift.diff
>
>
> 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.
[jira] Resolved: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-336.
--------------------------------------
Resolution: Fixed
Assignee: Jeff Hodges (was: Tim Huske)
committed with a few remaining changes (e.g. inlining SP insert/batch_insert, cleaning out unnecessary newlines in method args).
thanks for the work!
> 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
> Reporter: Evan Weaver
> Assignee: Jeff Hodges
> 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, CASSANDRA-336-v4-Adding-support-for-batch-mutations.patch, CASSANDRA-336-v5-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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evan Weaver updated CASSANDRA-336:
----------------------------------
Attachment: (was: CASSANDRA-336-deletes-in-BatchMutation.diff)
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-deletes-in-BatchMutation-2-code.diff
>
>
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Evan Weaver (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Evan Weaver updated CASSANDRA-336:
----------------------------------
Attachment: CASSANDRA-336-deletes-in-BatchMutation-2-gen-java.diff
> 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
> Reporter: Evan Weaver
> Assignee: Evan Weaver
> Attachments: CASSANDRA-336-deletes-in-BatchMutation-2-code.diff, CASSANDRA-336-deletes-in-BatchMutation-2-gen-java.diff
>
>
> 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.
[jira] Updated: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jeff Hodges (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Hodges updated CASSANDRA-336:
----------------------------------
Attachment: CASSANDRA-336-v3-Adding-support-for-batch-mutations.patch
This patch is nearly the same as v2 but does not included the generated thirft code and changes the reference to "keyspaces" in the commit message to "ColumnFamilies".
Obviously, the same change was meant in my comment that came with the v2 patch.
> 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.
[jira] Commented: (CASSANDRA-336) Merge batchmutation types and
support batched deletes
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ 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.