cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Updated: (CASSANDRA-3) Allow non-hash-based partitioning schemes to allow truly order-preserving storage
Date Wed, 11 Mar 2009 23:18:50 GMT


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

View raw message