Mailing-List: contact cassandra-commits-help@incubator.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Message-ID: <747652993.1236813530484.JavaMail.jira@brutus>
Date: Wed, 11 Mar 2009 16:18:50 -0700 (PDT)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: cassandra-commits@incubator.apache.org
Subject: [jira] Updated: (CASSANDRA-3) Allow non-hash-based partitioning
 schemes to allow truly order-preserving storage
In-Reply-To: <183783582.1236813053587.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jonathan Ellis updated CASSANDRA-3:
-----------------------------------

    Attachment: partition-3.patch

partition-3 consolidates partition behavior in IPartitioner, so creating a new partitioner should be only a matter of implementing that interface.  all the external switch statements on PartitionerType have been folded into that.

SSTable is now the only part of the code that cares about the distinction between a "raw" key and a "decorated" key.  variables in that class have been named clientKey or decoratedKey to show which is which.  others don't care either because they only deal with decorated keys (SequenceFile) or only with client keys (everyone else).  as part of this, I've merged some overloaded methods with substantially duplicated code to simplify auditing these changes.

> Allow non-hash-based partitioning schemes to allow truly order-preserving storage
> ---------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-3
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Jonathan Ellis
>         Attachments: partition-1.patch, partition-2.patch, partition-3.patch
>
>
> An order-preserving hash has too many limitations to be useful in production where key lengths tend to have low variance.  We need to make Cassandra more flexible and define a partitioner as responsible for String -> EndPoint instead of String -> BigInteger.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.