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 |
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 <[hidden email]> 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 > |
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 <[hidden email]> 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 <[hidden email] > > > 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 > > > |
+1 to Vladimir.
Sergi 2017-04-11 10:48 GMT+03:00 Vladimir Ozerov <[hidden email]>: > 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 <[hidden email] > > > 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 < > [hidden email] > > > > > 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 > > > > > > |
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 <[hidden email]> wrote: > +1 to Vladimir. > > Sergi > > 2017-04-11 10:48 GMT+03:00 Vladimir Ozerov <[hidden email]>: > > > 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 < > [hidden email] > > > > > 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 < > > [hidden email] > > > > > > > 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 > > > > > > > > > > |
Free forum by Nabble | Edit this page |