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 Mon, 11 Sep 2017 23:47:43 GMT
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.


On Mon, Sep 11, 2017 at 4:41 PM, Dmitriy Setrakyan <dsetrakyan@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.

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