ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Binary object hash code resolution in Apache Ignite 2.0
Date Fri, 27 Jan 2017 18:54:38 GMT
No, we didn't do that because it could break existing user code. Not a
problem for AI 2.0.

On Fri, Jan 27, 2017 at 9:50 PM, Denis Magda <dmagda@apache.org> wrote:

> Sounds reasonable to me. Actually, I thought that
> BinaryArrayIdentityResolver was already enabled by default since 1.8.
>
> —
> Denis
>
> > On Jan 27, 2017, at 2:37 AM, 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