ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: Default hash code generation strategy for new binary objects
Date Mon, 03 Oct 2016 12:03:45 GMT
Dima,

Why do you think somebody will need to override equals? Currently we do not
have such an ability and AFAIK we did not have a single question regarding
this. Other products, such as Hazelcast, rely solely on binary
representation of a key. If this is never used, why do we need to increase
the configuration complexity?

2016-10-01 5:25 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:

> 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