AffinityKeyMapper alternatives

[Valentin Kulichenko <va...@gmail.com>]

Guys,

Some time ago we deprecated AffinityKeyMapper in favor
of CacheKeyConfiguration#affinityKeyFieldName and AffinityKeyMapped
annotation. While I understand the reasons why we did this, I think it's
not very flexible as requires to specify the field name on node startup.

First of all, CacheKeyConfiguration is set on IgniteConfiguration, but not
CacheConfiguration. Does anyone knows why? How can I specify the affinity
field name if I create a new cache dynamically?

Second of all, AffinityKeyMapped doesn't always work. There are cases when
model classes can't be modified with Ignite annotations, for example. For
this case I suggest to introduce something like
AffinityKeyFieldNameResolver that will allow to implement custom logic
instead. Of course, it will work in the same way as annotation, i.e.
invoked on client side only. Is this possible?

-Val

Re: AffinityKeyMapper alternatives

[Vladimir Ozerov <vo...@gridgain.com>]

Val, Dima,
We already have per-cache key configuration:
CacheConfiguration.keyConfiguration.

Personally I vote for complete restriction of any runtime changes.
Everything should be specified in advance *before* cache is started.
@AffinityKeyMapped should be deprecated, as well as "affinityKey" should be
removed from binary metadata. Predefined affinity configuration would solve
a lot of issues:
1) We will be able to use it for SQL engine optimizations and UX
improvements. E.g. SqlFieldsQuery.collocated flag will not be needed
anymore, we will be able to determine whether distributed join is needed or
not, etc..
2) We will get consistent and predictable behavior. For example, currently
if I put an object with this annotation to cache, it will be used. But if I
put the same object through BinaryObjectBuilder, it will not be used ever.


On Wed, Sep 13, 2017 at 3:00 AM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:

> Dmitry,
>
> IMO, it's actually pretty typical for data grid use cases where affinity
> key is usually provided as part of key itself, i.e. after cache creation.
> In vast majority of cases I've seen, this is done via very popular
> @AffinityKeyMapped annotation.
>
> My only point is that the annotation can't always be used due to
> restrictions on application level. For example, an application I was
> recently working with has a platform that uses Ignite internally and
> provides its own API. Therefore it can't expose @AffinityKeyMapped to its
> users, but instead provides another annotation (and probably some other
> custom mechanisms). It currently uses deprecated AffinityKeyMapper to
> support this and there is no alternative. Just getting rid of it would mean
> changing and complicating the platform API.
>
> -Val
>
> On Mon, Sep 11, 2017 at 6:25 PM Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
> > On Mon, Sep 11, 2017 at 4:47 PM, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com> wrote:
> >
> > > Even if CacheKeyConfiguration is part of CacheConfiguration, the
> affinity
> > > key field name can be provided only on cache startup. In many cases
> this
> > > name can be resolved only based on the actual key instance, e.g. during
> > > first put. Per my understanding, this already works with annotation, I
> > just
> > > propose more flexible solution for rare cases when annotation can't be
> > > used. Basically, the logic we currently have would become the default
> > > implementation of the resolver.
> > >
> >
> > Val, the use case seems very strange to me. How can you not know the
> > affinity key field in advance? Can you provide an example from the field?
> >
>

Re: AffinityKeyMapper alternatives

[Valentin Kulichenko <va...@gmail.com>]

Dmitry,

IMO, it's actually pretty typical for data grid use cases where affinity
key is usually provided as part of key itself, i.e. after cache creation.
In vast majority of cases I've seen, this is done via very popular
@AffinityKeyMapped annotation.

My only point is that the annotation can't always be used due to
restrictions on application level. For example, an application I was
recently working with has a platform that uses Ignite internally and
provides its own API. Therefore it can't expose @AffinityKeyMapped to its
users, but instead provides another annotation (and probably some other
custom mechanisms). It currently uses deprecated AffinityKeyMapper to
support this and there is no alternative. Just getting rid of it would mean
changing and complicating the platform API.

-Val

On Mon, Sep 11, 2017 at 6:25 PM Dmitriy Setrakyan <ds...@apache.org>
wrote:

> On Mon, Sep 11, 2017 at 4:47 PM, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
> > Even if CacheKeyConfiguration is part of CacheConfiguration, the affinity
> > key field name can be provided only on cache startup. In many cases this
> > name can be resolved only based on the actual key instance, e.g. during
> > first put. Per my understanding, this already works with annotation, I
> just
> > propose more flexible solution for rare cases when annotation can't be
> > used. Basically, the logic we currently have would become the default
> > implementation of the resolver.
> >
>
> Val, the use case seems very strange to me. How can you not know the
> affinity key field in advance? Can you provide an example from the field?
>

Re: AffinityKeyMapper alternatives

[Dmitriy Setrakyan <ds...@apache.org>]

On Mon, Sep 11, 2017 at 4:47 PM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:

> Even if CacheKeyConfiguration is part of CacheConfiguration, the affinity
> key field name can be provided only on cache startup. In many cases this
> name can be resolved only based on the actual key instance, e.g. during
> first put. Per my understanding, this already works with annotation, I just
> propose more flexible solution for rare cases when annotation can't be
> used. Basically, the logic we currently have would become the default
> implementation of the resolver.
>

Val, the use case seems very strange to me. How can you not know the
affinity key field in advance? Can you provide an example from the field?

Re: AffinityKeyMapper alternatives

[Valentin Kulichenko <va...@gmail.com>]

Even if CacheKeyConfiguration is part of CacheConfiguration, the affinity
key field name can be provided only on cache startup. In many cases this
name can be resolved only based on the actual key instance, e.g. during
first put. Per my understanding, this already works with annotation, I just
propose more flexible solution for rare cases when annotation can't be
used. Basically, the logic we currently have would become the default
implementation of the resolver.

-Val

On Mon, Sep 11, 2017 at 4:41 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:

> On Mon, Sep 11, 2017 at 4:01 PM, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
> > Guys,
> >
> > Some time ago we deprecated AffinityKeyMapper in favor
> > of CacheKeyConfiguration#affinityKeyFieldName and AffinityKeyMapped
> > annotation. While I understand the reasons why we did this, I think it's
> > not very flexible as requires to specify the field name on node startup.
> >
> > First of all, CacheKeyConfiguration is set on IgniteConfiguration, but
> not
> > CacheConfiguration. Does anyone knows why? How can I specify the affinity
> > field name if I create a new cache dynamically?
> >
>
> Ouch... really? Just looking at the name of the configuration class, I
> would assume that it belongs to CacheConfiguration. Can this be fixed?
>
>
> >
> > Second of all, AffinityKeyMapped doesn't always work. There are cases
> when
> > model classes can't be modified with Ignite annotations, for example. For
> > this case I suggest to introduce something like
> > AffinityKeyFieldNameResolver that will allow to implement custom logic
> > instead. Of course, it will work in the same way as annotation, i.e.
> > invoked on client side only. Is this possible?
> >
>
> But wouldn't CacheKeyConfiguration provide this information if it was the
> property of the CacheConfiguration and not IgniteConfiguration? I don't
> think we need a resolver.
>

Re: AffinityKeyMapper alternatives

[Dmitriy Setrakyan <ds...@apache.org>]

On Mon, Sep 11, 2017 at 4:01 PM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:

> Guys,
>
> Some time ago we deprecated AffinityKeyMapper in favor
> of CacheKeyConfiguration#affinityKeyFieldName and AffinityKeyMapped
> annotation. While I understand the reasons why we did this, I think it's
> not very flexible as requires to specify the field name on node startup.
>
> First of all, CacheKeyConfiguration is set on IgniteConfiguration, but not
> CacheConfiguration. Does anyone knows why? How can I specify the affinity
> field name if I create a new cache dynamically?
>

Ouch... really? Just looking at the name of the configuration class, I
would assume that it belongs to CacheConfiguration. Can this be fixed?


>
> Second of all, AffinityKeyMapped doesn't always work. There are cases when
> model classes can't be modified with Ignite annotations, for example. For
> this case I suggest to introduce something like
> AffinityKeyFieldNameResolver that will allow to implement custom logic
> instead. Of course, it will work in the same way as annotation, i.e.
> invoked on client side only. Is this possible?
>

But wouldn't CacheKeyConfiguration provide this information if it was the
property of the CacheConfiguration and not IgniteConfiguration? I don't
think we need a resolver.