[
https://issues.apache.org/jira/browse/CASSANDRA-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127618#comment-13127618
]
Sylvain Lebresne commented on CASSANDRA-3067:
---------------------------------------------
Had an initial look at the patches. I haven't try applying the patches yet
(which likely need rebase anyway), so following comments are fairly high level.
For the abstract interfaces to SSTable{Reader, Writer, *Iterator}, I would
prefer calling them AbstractSSTable* and keep the concrete implementation with
their current name. It should make the diffs much more digestible and much more
easy to check. Same thing for future merges. And we kind of use Abstract* for
abstract place around the place so it would rather more consistent than less.
For patch 2, I'm not too sure about what this refactoring buys us, in
particular as long as files are versioned by one character. I understand that
to support other kind of sstables, we would need to somehow distinguish between
"kind" of sstables, but this doesn't seem to fully solve that problem. I think
we already had kind of the same problem with compression, where we went with
using the presence of a sstable component to decide if it's compressed or not.
I'm happy to have a discussion on how to best evolve the sstable versioning but
not sure about the solution here. Follows the same holds for patch 6.
Small nitpick: In patch1, I'm not too fond of introducing a compareTo for
SSTableIdentityIterator (given a SSTableIdentityIterator is not really equal to
it's key), is there an underlying reason ?
> Simple SSTable Pluggability
> ---------------------------
>
> Key: CASSANDRA-3067
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3067
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Stu Hood
> Assignee: Stu Hood
> Fix For: 1.1
>
> Attachments:
> 0001-CASSANDRA-3067-Create-an-ABC-for-SSTableIdentityIterat.txt,
> 0002-CASSANDRA-3067-Move-from-linear-SSTable-versions-to-fe.txt,
> 0003-CASSANDRA-3067-Create-an-ABC-for-SSTableWriter.txt,
> 0004-CASSANDRA-3067-Rename-SSTable-Names-Slice-Iterator-to-.txt,
> 0005-CASSANDRA-3067-Create-ABCs-for-SSTableReader-and-KeyIt.txt,
> 0006-CASSANDRA-3067-Allow-overriding-the-current-sstable-ve.txt
>
>
> CASSANDRA-2995 proposes full storage engine pluggability, which is probably
> unavoidable in the long run. For now though, I'd like to propose an
> incremental alternative that preserves the sstable model, but allows it to
> evolve non-linearly.
> The sstable "version" field could allow for simple switching between writable
> sstable types, without moving all the way to differentiating between engines
> as CASSANDRA-2995 requires. This can be accomplished by moving towards a
> "feature flags" model (with a mapping between versions and feature sets),
> rather than a linear versions model (where versions can be strictly ordered
> and all versions above X have a feature).
> There are restrictions on this approach:
> * It's sufficient for an alternate SSTable(Writer|Reader|*) set to require a
> patch to enable (rather than a JAR)
> * Filenames/descriptors/components must conform to the existing conventions
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
