Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <1779910277.1240432607444.JavaMail.jira@brutus>
Date: Wed, 22 Apr 2009 13:36:47 -0700 (PDT)
From: "Erik Holstad (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Commented: (HBASE-1336) Splitting up the compare of
 family+column into 2 different compares
In-Reply-To: <1021642707.1240432367436.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Erik Holstad commented on HBASE-1336:
-------------------------------------

The way I see it we can do this in two different ways, first one is to compare the family length first and then the whole (family+columns) byte[] or we can compare the 
family first and then the column. I have used the second approach for all the places that I'm comparing in the new server implementation. The first approach might be better
if you can actually do memcompare on byte[]. I our case I don't think it will matter, since we still need to compare byte by byte. 

> Splitting up the compare of family+column into 2 different compares
> -------------------------------------------------------------------
>
>                 Key: HBASE-1336
>                 URL: https://issues.apache.org/jira/browse/HBASE-1336
>             Project: Hadoop HBase
>          Issue Type: Bug
>    Affects Versions: 0.20.0
>            Reporter: Erik Holstad
>
> When comparing family+column you can end up in  a situation like column1 is "abcd:efg" and column2 is "abc:defg" which in the current implementation of
> KeyValue.KeyComparator.compare will result in a faulty result.

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