[
https://issues.apache.org/jira/browse/CASSANDRA-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033124#comment-13033124
]
Sylvain Lebresne commented on CASSANDRA-1610:
---------------------------------------------
Looking quickly through that code, it looks a good chunk of the code is here to
support the expiring of sstables, and it's pretty much hardcoded. Isn't there a
way to encapsulate that better ? All the part about collecting and keeping the
max timestamp in a sstable also doesn't really strike me as making the
compaction more pluggable.
I'm not necessarily saying the TimestampBucketedCompactionStrategy is not
useful (but I'm not saying it is either), 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.
> 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
