Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <51599F8A.60306@mechnicality.com>
Date: Mon, 01 Apr 2013 07:54:02 -0700
From: Alan Chaney <alan@mechnicality.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "user@hbase.apache.org" <user@hbase.apache.org>
Subject: Inconsistencies in comparisons using KeyComparator
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi

I need to write some code that sorts row keys identically to HBase.

I looked at the KeyValue.KeyComparator code, and it seems that, by 
default, HBase elects to use the 'Unsafe' comparator as the basis of its 
comparison, with a fall-back to to the PureJavaComparer should Unsafe 
not be available (for example, in tests.)

However, I'm finding that the sort order from a call to 
KeyValue.KeyComparator appears to be inconsistent between the two forms.

As an example, comparing:

(first param) (second param)
0000000000000000ffffffffffffffffffffffffffffffff616c1b to 
0000000000000000ffffffffffffffffffffffffffffffff61741b

gives 1 for the default (presumably, Unsafe) call, and -1 using the 
PureJavaComparator.

I would actually expect it to be a -ve number, based on the difference 
of 6c to 74 in the 3rd from last byte above.

Similarly

000000000000000000000000000000000000000000000000616c1b to 
0000000000000000000000000000000000000000000000061741b

gives > 0 instead of < 0. The PureJavaComparator does a byte-by-byte 
comparison by

Is this expected? From the definition of lexicographical compare that I 
found, I don't think so. There's no issue of signed comparison here, 
because 0x6c and 0x74 are still +ve byte values.

Regards

Alan