ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Binary object hash code resolution in Apache Ignite 2.0
Date Fri, 27 Jan 2017 17:32:21 GMT
Why shouldn't we use Object.hashCode() by default, even if the equals check
is done by comparing byte arrays? Wouldn't it be faster?

On Fri, Jan 27, 2017 at 4:38 AM, Pavel Tupitsyn <ptupitsyn@apache.org>
wrote:

> Makes sense to me.
>
> Ticket for reference: https://issues.apache.org/jira/browse/IGNITE-4558
>
> On Fri, Jan 27, 2017 at 1:37 PM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
>
> > Folks,
> >
> > Historically we have fundamental flaw in how we deal with hashCode/equals
> > for BinaryObjects:
> > 1) hashCode() is taken from original deserialized object.
> > 2) But equals() is performed through binary array comparison.
> >
> > We recently introduced BinaryIdentityResolver [1] as a part of DML
> feature,
> > but we didn't change any existing semantics, because it might broke
> > applications running AI 1.x.
> >
> > Now I am thinking on how it should be designed properly in AI 2.0, and
> here
> > is my idea:
> > 1) Every type will use BinaryArrayIdentityResolver [2] unless it is
> > overridden in config
> > 2) Hash code is calculated only using resolver
> > 3) Equality is determined only using resolver
> > 4) Never ever use Object.hashCode().
> >
> > This way we will have clean and consistent hashCode/equals semantics.
> >
> > Any objections or comments?
> >
> > Vladimir.
> >
> > [1]
> > https://github.com/apache/ignite/blob/master/modules/
> > core/src/main/java/org/apache/ignite/binary/BinaryIdentityResolver.java
> > [2]
> > https://github.com/apache/ignite/blob/master/modules/
> > core/src/main/java/org/apache/ignite/binary/BinaryArrayIdentityResolver.
> > java
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message