[
https://issues.apache.org/jira/browse/CASSANDRA-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864918#action_12864918
]
Gary Dusbabek commented on CASSANDRA-293:
-----------------------------------------
This is all done except for figuring out a way to hint range mutations during a
partition.
I've had several ideas that would keep all hints in the same CF that won't work
for various reasons. The current single-key way of storing hints using
pointers just doesn't translate over to ranges.
I'm looking at using a second hint CF to store messages for range operations
and forward them when the node comes back. This works as long as the affects
of a message are idempotent.
The downsides are that hints are stored in two places and that earlier range
messages that have been superseded by later messages still need to be forwarded
because there is no easy calculation to determine whether or not an earlier
message is still relevant.
Anybody see a problem with this approach?
> remove_key_range operation
> --------------------------
>
> Key: CASSANDRA-293
> URL: https://issues.apache.org/jira/browse/CASSANDRA-293
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Mark Robson
> Assignee: Gary Dusbabek
> Priority: Minor
> Fix For: 0.7
>
> Attachments: 0001-thrift-changes.patch,
> 0002-add-flexibility-to-commit-log-serialization.patch,
> 0003-remove-unused-parts-of-WriteResponse.patch,
> 0004-RangeRemoveCommand-and-LocalRangeDeletion.patch, 0005-unit-tests.patch,
> 0006-alter-hint-format.patch,
> 0007-refactor-HHOM-to-handle-new-hint-format.patch
>
>
> For cleaning up old data on a rotating basis, a removal operation which
> operates on key ranges would be very handy, currently we have to remove every
> single column individually.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
