You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Sergi Vladykin <se...@gmail.com> on 2017/04/11 07:32:45 UTC
AffinityKeyMapper: break compatibility before 2.0
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
Re: AffinityKeyMapper: break compatibility before 2.0
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <se...@gmail.com>
wrote:
> +1 to Vladimir.
>
> Sergi
>
> 2017-04-11 10:48 GMT+03:00 Vladimir Ozerov <vo...@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
> > > >
> > >
> >
>
Re: AffinityKeyMapper: break compatibility before 2.0
Posted by Sergi Vladykin <se...@gmail.com>.
+1 to Vladimir.
Sergi
2017-04-11 10:48 GMT+03:00 Vladimir Ozerov <vo...@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
> > >
> >
>
Re: AffinityKeyMapper: break compatibility before 2.0
Posted by Vladimir Ozerov <vo...@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 <ds...@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
> >
>
Re: AffinityKeyMapper: break compatibility before 2.0
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <se...@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
>