Because it breaks equals/hashCode contract and cannot work with DML (we use ugly hack as a workaround now).
27 янв. 2017 г. 20:33 пользователь "Dmitriy Setrakyan" < [email protected]> написал: > 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 <[email protected]> > 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 <[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 > > > > > >
