Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CA+eZwrEPG_0EpEG+z1oSHjij7dyKa434+tQK=kchQpSb4mRrEg@mail.gmail.com>
References: <CA+eZwrFziid76Os9x1FrZJfhkoGVXKKTG=zWT=hM37q8246Bog@mail.gmail.com>
 <CA+0=VoVSogMXAoYPbOt-CRVz7j_xomq_YR1vV1r5XbsGR1Mgbg@mail.gmail.com>
 <CAGt6o8npq5w6p=6ogTtT8F=vnG8Wsk9pRziqKyK4ePtegG5_NQ@mail.gmail.com> <CA+eZwrEPG_0EpEG+z1oSHjij7dyKa434+tQK=kchQpSb4mRrEg@mail.gmail.com>
From: Dmitriy Setrakyan <dsetrakyan@apache.org>
Date: Tue, 11 Apr 2017 10:05:41 -0700
Message-ID: <CA+0=VoUcLDwgHBm=6UwYqZLUyiQ9-HwcBsMX2Q_BsTRuObkBwg@mail.gmail.com>
Subject: Re: AffinityKeyMapper: break compatibility before 2.0
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a114ff3b6706727054ce71c4a
archived-at: Tue, 11 Apr 2017 17:06:24 -0000

--001a114ff3b6706727054ce71c4a
Content-Type: text/plain; charset=UTF-8

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
> > > >
> > >
> >
>

--001a114ff3b6706727054ce71c4a--