Current design is documented here: https://issues.apache.org/jira/browse/IGNITE-4011, it incorps both equals and hashCode.
- Alex 2016-10-03 15:24 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > On Mon, Oct 3, 2016 at 5:03 AM, Alexey Goncharuk <alexey.goncha...@gmail.com >> wrote: > >> 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? >> > > Agree. As I mentioned, let's proceed with the current design and see if > anyone asks to override "equals" method. We can always add it later. > > >> >> 2016-10-01 5:25 GMT+03:00 Dmitriy Setrakyan <dsetrak...@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.pasche...@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 <dsetrak...@apache.org>: >> > > > On Thu, Sep 29, 2016 at 9:57 AM, Denis Magda <dma...@gridgain.com> >> > > wrote: >> > > > >> > > >> Alex, >> > > >> >> > > >> A minor note regarding this >> > > >> >> > > >> > On Sep 29, 2016, at 8:39 AM, Alexey Goncharuk < >> > > >> alexey.goncha...@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 >> > > >> > >>
