ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: AffinityKeyMapper: break compatibility before 2.0
Date Tue, 11 Apr 2017 17:05:41 GMT
OK, let's drop it. But we should provide clear instructions in the 2.0
migration guide about this change.

On Tue, Apr 11, 2017 at 1:33 AM, Sergi Vladykin <sergi.vladykin@gmail.com>
wrote:

> +1 to Vladimir.
>
> Sergi
>
> 2017-04-11 10:48 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:
>
> > Dima,
> >
> > The whole idea of AffinityKeyMapper appears to be wrong since we will
> have
> > only BinaryMarshaller. We do not have classes on server, how can we rely
> on
> > interface this class extends? I think we should do the following:
> > 1) Allow @AffinityKeyMapped annotation on fields only (it doesn't work on
> > methods with binary anyway).
> > 2) Drop AffinityKeyMapper completely.
> > 3) Hopefully, at some point we will implement old Yakov's idea of
> > declarative extensions to binary objects, which will handle "affintiy
> key",
> > "equals/hashCode" and "compareTo" cases without necessity to have any
> > interface implementation classes on the server.
> >
> > Thoughts?
> >
> > On Tue, Apr 11, 2017 at 10:41 AM, Dmitriy Setrakyan <
> dsetrakyan@apache.org
> > >
> > wrote:
> >
> > > I agree that this interface is problematic. However, I don't think that
> > > dropping it right away would be fair to our users. Can we deprecate it
> > and
> > > print out a warning that AffinityKeyMapper cannot be used with DDL
> > > statements?
> > >
> > > D.
> > >
> > > On Tue, Apr 11, 2017 at 12:32 AM, Sergi Vladykin <
> > sergi.vladykin@gmail.com
> > > >
> > > wrote:
> > >
> > > > Guys,
> > > >
> > > > We are moving in direction of better distributed SQL support, it
> means
> > > that
> > > > we always will need to know an affinity field name for key type.
> > > >
> > > > Now we have AffinityKeyMapper which hides it from us.
> > > >
> > > > Since we have other means of configuring the affinity key, e.g
> > > > CacheKeyConfiguration and @AffinityKeyMapped, I suggest to either
> drop
> > > this
> > > > interface or change it so that it just return affinity key field name
> > > > instead of the affinity key field value. I prefer dropping it.
> > > >
> > > > What do you think?
> > > >
> > > > Sergi
> > > >
> > >
> >
>

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