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