I think hash code can be calculated during serialization, while we write
bytes. Obviously, there is no reason to calculate it each time hashCode()
is called on the same binary object.
-Val
On Fri, Jan 27, 2017 at 10:59 AM, Dmitriy Setrakyan
wrote:
> On Fri, Jan 27, 2017 at 9:56 AM, Vladimir Oze
On Fri, Jan 27, 2017 at 9:56 AM, Vladimir Ozerov
wrote:
> Because it breaks equals/hashCode contract and cannot work with DML (we use
> ugly hack as a workaround now).
>
Got it. Perhaps we can calculate hashCode only over the first 10 bytes or
so, for performance reasons.
>
> 27 янв. 2017 г. 2
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 wrote:
> Sounds reasonable to me. Actually, I thought that
> BinaryArrayIdentityResolver was already enabled by default since 1.8.
>
> —
> Denis
>
> > On Jan 27
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 wrote:
>
> Folks,
>
> Historically we have fundamental flaw in how we deal with hashCode/equals
> for BinaryObjects:
>
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" <
dsetrak...@apache.org> написал:
> Why shouldn't we use Object.hashCode() by default, even if the equals check
> is done by comparing
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
wrote:
> Makes sense to me.
>
> Ticket for reference: https://issues.apache.org/jira/browse/IGNITE-4558
>
> On Fri,
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
wrote:
> Folks,
>
> Historically we have fundamental flaw in how we deal with hashCode/equals
> for BinaryObjects:
> 1) hashCode() is taken from original d
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,
b
