[jira] Commented: (HBASE-661) Allow to specify a user supplied row key comparator for a table

["Clint Morgan (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629639#action_12629639 ] 

Clint Morgan commented on HBASE-661:
------------------------------------

This seems easy enough at first glance. Just associate an (optional) WritableCompartor<byte[]> with each table. If a table has this comparator then use it (this logic seems to belong in the new HStoreKey.compareTwoRowKeys).

Things get more tricky I think when taking the META table into account. I suppose I need to rework the way META rows are being compared to use the tables comparator for the row's bits in each meta key.

So If I have two tables A, and B with 2 regions each, and B has a custom, reverse, comparator, then I want a META laid out like:

A,1,5
A,5,
B,9,5
B,5,

So basically the META table uses a custom comparator that is composed of the comparators for each Table.

Any advice before I start digging deeper? Are there many places where we assume that row keys are lexocographiclly sorted?

> Allow to specify a user supplied row key comparator for a table 
> ----------------------------------------------------------------
>
>                 Key: HBASE-661
>                 URL: https://issues.apache.org/jira/browse/HBASE-661
>             Project: Hadoop HBase
>          Issue Type: New Feature
>          Components: client, master, regionserver
>    Affects Versions: 0.2.0
>            Reporter: Clint Morgan
>            Assignee: Clint Morgan
>
> Now that row keys are byte arrays, users should be able to specify a comparator at table creation time.
> My use case for this is to implement secondary indexes. In this case, row keys for the index tables will be constructed from an optional prefix of the original row key as well as the content of column that is being indexed. Then the comparator will first compare based on the key prefix, and break ties by deserializing the column values and using the deserialized type's compareTo method.

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