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" sho
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 a
On Mon, Sep 11, 2017 at 4:47 PM, Valentin Kulichenko <
valentin.kuliche...@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 in
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
prop
On Mon, Sep 11, 2017 at 4:01 PM, Valentin Kulichenko <
valentin.kuliche...@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 thin
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, CacheKey
