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 >
