Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: unknown (nike.apache.org: error in processing during lookup of
 clehene@adobe.com)
From: Cosmin Lehene <clehene@adobe.com>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Subject: Re: Why doesn't KeyValue.equals/CellComparator compare the values?
Thread-Topic: Why doesn't KeyValue.equals/CellComparator compare the values?
Thread-Index: AQHPM2uAMcbfAX8Bl06YOtSggmNPQ5rIgpwAgADoSACAAQu8AA==
Date: Fri, 28 Feb 2014 18:20:43 +0000
Message-ID: <CF360ABD.6B6B0%clehene@adobe.com>
References: <CF33F00A.6B3EB%clehene@adobe.com>
 <CAOKsKJVbDT9uUK_1FzHa4hCqh6QL_5OFr2hZwomJivganqv2yQ@mail.gmail.com>
 <CADcMMgG8o7-SL_uTbO2GC2kcw=i+WM_R7msTE-0-4k+RqZYdLg@mail.gmail.com>
In-Reply-To: 
 <CADcMMgG8o7-SL_uTbO2GC2kcw=i+WM_R7msTE-0-4k+RqZYdLg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.9.131030
received-spf: None (: adobe.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <59C44A6FEC9634449A44AC70B49F0A40@namprd02.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Thanks Matt, Stack,

My question/comment was biased by the perspective of a co-processor
implementation, but I guess it may well apply for HBase development.
>From that perspective you're both in HBase-land and Java-land.

A collection of cells needs to be compared to another collection of cells
(I=B9m doing a diff).
Java collections will end up comparing individual objects for equality so
it boils down to a Cell object being equal to another Cell object. So from
a java/oo perspective the question is: are two cells with different values
equal (I.e. Can I swap them?)

The HBase answer is indeed yes they are equal as long as row, family,
qualifier, timestamp and type are the same.

The Java answer, however may be different (and hence the expectations of a
developer) as, in general it will be based on the known contract.

And the general hashCode  contract is

* If two objects are equal according to the equals(Object) method, then
calling the hashCode method on each of the two objects must produce the
same integer result.


And the equals javadoc

* Note that it is generally necessary to override the {@code hashCode}
     * method whenever this method is overridden, so as to maintain the
     * general contract for the {@code hashCode} method, which states
     * that equal objects must have equal hash codes.


But in our case, the object equality will pass but hash codes will be
different (https://gist.github.com/clehene/9276434)

It=B9s obvious why the behavior is as is in Hbase, so rather than
nitpicking, I wonder whether this could be made obvious as it may help
avoid some unexpected behaviors :)

Thanks,
Cosmin

On 2/27/14, 10:22 AM, "Stack" <stack@duboce.net> wrote:

>On Wed, Feb 26, 2014 at 8:31 PM, Matt Corgan <mcorgan@hotpads.com> wrote:
>....
>
>> But maybe one of the committers could add a sentence to emphasize that
>> value is excluded.
>>
>>
>We should underline that data is not considered comparing Cells
>(KeyValues).  Apart from the fact that it could make for some interesting
>performance issues, the system isn't plumbed for dealing with coordinates
>that differ in their value only.  Rather, the mvcc/sequenceid is used
>splitting Cells whose coordinates are otherwise the same).
>
>What was your expectation mighty Cosmin?  What you think HBase should do
>with values that differ in value only?
>
>Thanks,
>St.Ack