+1 to Vladimir. Sergi
2017-04-11 10:48 GMT+03:00 Vladimir Ozerov <voze...@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 <dsetrak...@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.vlady...@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 > > > > > >
