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 <[email protected]> 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 <[email protected] > > > 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 > > >
