[
https://issues.apache.org/jira/browse/CASSANDRA-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033152#comment-13033152
]
Stu Hood commented on CASSANDRA-1610:
-------------------------------------
bq. but at the very least I think that what this patch does should be redefined
clearly (it's not what I call making compaction pluggable, at least not just
that), and I'm pretty sure it does multiple think and that I'm not necessary ok
with all these things equally.
Agreed. Alan: would you mind overhauling the description of this ticket to
better describe the goals?
As usual, the problem with making something pluggable is that you need at least
2 implementations of the interface to make it worthwhile. We could separate out
the TimestampBucketedCompactionStrategy and its required additions into a
separate ticket, but it would be a mostly symbolic split. One split that might
be reasonable (but which I'm sure Alan would prefer to avoid) would be to add
TimeBucketed in this ticket, but to split out implementing expiration into a
separate ticket.
> Pluggable Compaction
> --------------------
>
> Key: CASSANDRA-1610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1610
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Chris Goffinet
> Assignee: Alan Liang
> Priority: Minor
> Labels: compaction
> Fix For: 1.0
>
> Attachments: 0001-move-compaction-code-into-own-package.patch,
> 0002-Pluggable-Compaction-and-Expiration.patch
>
>
> In CASSANDRA-1608, I proposed some changes on how compaction works. I think
> it also makes sense to allow the ability to have pluggable compaction per CF.
> There could be many types of workloads where this makes sense. One example we
> had at Digg was to completely throw away certain SSTables after N days.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
