ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: AffinityKeyMapper alternatives
Date Wed, 13 Sep 2017 00:00:33 GMT
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 <dsetrakyan@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?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message