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 <[email protected]> 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
