Default hash code generation strategy for new binary objects

[Denis Magda]

Alex,

A minor note regarding this

> On Sep 29, 2016, at 8:39 AM, Alexey Goncharuk <[hidden email]> 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.

—
Denis

[dsetrakyan]

On Thu, Sep 29, 2016 at 9:57 AM, Denis Magda <[hidden email]> wrote:

> Alex,
>
> A minor note regarding this
>
> > On Sep 29, 2016, at 8:39 AM, Alexey Goncharuk <
> [hidden email]> 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

[al.psc]

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 <[hidden email]>:

> On Thu, Sep 29, 2016 at 9:57 AM, Denis Magda <[hidden email]> wrote:
>
>> Alex,
>>
>> A minor note regarding this
>>
>> > On Sep 29, 2016, at 8:39 AM, Alexey Goncharuk <
>> [hidden email]> 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

[dsetrakyan]

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 <
[hidden email]> 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 <[hidden email]>:
> > On Thu, Sep 29, 2016 at 9:57 AM, Denis Magda <[hidden email]>
> wrote:
> >
> >> Alex,
> >>
> >> A minor note regarding this
> >>
> >> > On Sep 29, 2016, at 8:39 AM, Alexey Goncharuk <
> >> [hidden email]> 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
>

[Alexey Goncharuk]

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 <[hidden email]>:

> 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 <
> [hidden email]> 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 <[hidden email]>:
> > > On Thu, Sep 29, 2016 at 9:57 AM, Denis Magda <[hidden email]>
> > wrote:
> > >
> > >> Alex,
> > >>
> > >> A minor note regarding this
> > >>
> > >> > On Sep 29, 2016, at 8:39 AM, Alexey Goncharuk <
> > >> [hidden email]> 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
> >
>

[dsetrakyan]

On Mon, Oct 3, 2016 at 5:03 AM, Alexey Goncharuk <[hidden email]
> 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 <[hidden email]>:
>
> > 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 <
> > [hidden email]> 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 <[hidden email]>:
> > > > On Thu, Sep 29, 2016 at 9:57 AM, Denis Magda <[hidden email]>
> > > wrote:
> > > >
> > > >> Alex,
> > > >>
> > > >> A minor note regarding this
> > > >>
> > > >> > On Sep 29, 2016, at 8:39 AM, Alexey Goncharuk <
> > > >> [hidden email]> 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
> > >
> >
>

[al.psc]

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 <[hidden email]>:

> On Mon, Oct 3, 2016 at 5:03 AM, Alexey Goncharuk <[hidden email]
>> 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 <[hidden email]>:
>>
>> > 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 <
>> > [hidden email]> 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 <[hidden email]>:
>> > > > On Thu, Sep 29, 2016 at 9:57 AM, Denis Magda <[hidden email]>
>> > > wrote:
>> > > >
>> > > >> Alex,
>> > > >>
>> > > >> A minor note regarding this
>> > > >>
>> > > >> > On Sep 29, 2016, at 8:39 AM, Alexey Goncharuk <
>> > > >> [hidden email]> 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
>> > >
>> >
>>