ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Default hash code generation strategy for new binary objects
Date Sat, 01 Oct 2016 02:25:09 GMT
Alex,

I can't post in the ticket, because my Jira login stopped working, so I
will post here.

I only have 1 question - do we purposely not support custom equals
implementation? Seems we could simply add 2 methods to the
BinaryObjectHashCodeResolver: isUseEquals() and computeEquals(). Having
said that, I am OK with current design, we can always add equals support
later.

Otherwise, looks good.

D.

On Thu, Sep 29, 2016 at 5:19 PM, Alexander Paschenko <
alexander.a.paschenko@gmail.com> wrote:

> I've posted proposed example of hash code resolver interface and XML
> configuration for classless key on issue page
> https://issues.apache.org/jira/browse/IGNITE-2294.
>
> 2016-09-29 20:16 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:
> > On Thu, Sep 29, 2016 at 9:57 AM, Denis Magda <dmagda@gridgain.com>
> wrote:
> >
> >> Alex,
> >>
> >> A minor note regarding this
> >>
> >> > On Sep 29, 2016, at 8:39 AM, Alexey Goncharuk <
> >> alexey.goncharuk@gmail.com> wrote:
> >> >
> >> > A set of fields participating in hashCode and equals is impossible to
> >> > change without cluster restart.
> >>
> >> It’s unlikely that someone will change a key or at least it should be a
> >> rare or accidental operation. In any case if this happens a user must
> >> upgrade all the keys he already has in a cache. To resolve this it’s
> >> simpler to create a new cache with updated configuration and populate
> data
> >> there. This will not require us to restart a cluster.
> >>
> >
> > We should have a check in code that would prohibit changing hashcode
> fields
> > or the hashcode resolver class within the same cache. Using a different
> > cache to store the keys with new hashcodes is always an option and does
> not
> > require anything special from our side.
> >
> >
> >>
> >> —
> >> Denis
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message