[
https://issues.apache.org/jira/browse/CASSANDRA-7443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169246#comment-14169246
]
T Jake Luciani commented on CASSANDRA-7443:
-------------------------------------------
bq. force format-implementors to provide 'legacy' sstable scanners that
generate OnDiskAtomIterators that work the same way as the current format.
Not sure I follow, the iterator must still return data in the same order
regardless of the format. Out of Comparator order will throw an exception in
the ColumnFamily. We could add an explicit check lower down in the code but
then it's redundant IMO.
bq. keepExistingFormat in compaction task should probably be handled some other
way? should be possible to generate data, switch format and validate what we
get?
I only added this for A test case where you stream in data from a new format
and compact it in the same format (without globally requiring all sstables to
be written in the same format)
Outside of tests it should not be allowed. I can add a @VisibleForTesting and a
better comment.
I'll fix the other nits and rebase
> SSTable Pluggability v2
> -----------------------
>
> Key: CASSANDRA-7443
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7443
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: T Jake Luciani
> Assignee: T Jake Luciani
> Fix For: 3.0
>
> Attachments: 7443-refactor-v1.txt, 7443-testformat-v1.txt
>
>
> As part of a wider effort to improve the performance of our storage engine we
> will need to support basic pluggability of the SSTable reader/writer. We
> primarily need this to support the current SSTable format and new SSTable
> format in the same version. This will also let us encapsulate the changes in
> a single layer vs forcing the whole engine to change at once.
> We previously discussed how to accomplish this in CASSANDRA-3067
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
