Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 9 Jul 2013 17:03:50 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12519724.1314039586183.19539.1373389430151@arcas>
In-Reply-To: <JIRA.12519724.1314039586183@arcas>
References: <JIRA.12519724.1314039586183@arcas>
Subject: [jira] [Resolved] (CASSANDRA-3067) Simple SSTable Pluggability
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sylvain Lebresne resolved CASSANDRA-3067.
-----------------------------------------

    Resolution: Won't Fix

Closing this for lack of progress. I'm also not sure this is buying us much in practice in itself. Feel free to re-open if you want to revisit this.
                
> 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
>         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
For more information on JIRA, see: http://www.atlassian.com/software/jira