[jira] [Updated] (CASSANDRA-3067) Simple SSTable Pluggability

2011-12-15 Thread Jonathan Ellis (Updated) (JIRA)

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

Jonathan Ellis updated CASSANDRA-3067:
--

Fix Version/s: (was: 1.1)

 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: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (CASSANDRA-3067) Simple SSTable Pluggability

2011-08-23 Thread Stu Hood (JIRA)

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

Stu Hood updated CASSANDRA-3067:


Attachment: 0006-CASSANDRA-3067-Allow-overriding-the-current-sstable-ve.txt
0005-CASSANDRA-3067-Create-ABCs-for-SSTableReader-and-KeyIt.txt
0004-CASSANDRA-3067-Rename-SSTable-Names-Slice-Iterator-to-.txt
0003-CASSANDRA-3067-Create-an-ABC-for-SSTableWriter.txt
0002-CASSANDRA-3067-Move-from-linear-SSTable-versions-to-fe.txt
0001-CASSANDRA-3067-Create-an-ABC-for-SSTableIdentityIterat.txt

Patchset to create all necessary abstract base classes for SSTable pluggability.

0002 and 0006 deal with allowing for non-linear SSTable versions, and 
overriding the default.

This set applies atop CASSANDRA-2629 but should be ready for high level review.

 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.0

 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira