Alex,

To be honest, I don't understand the reasoning behind the removal. I think
resolvers provide good flexibility for different corner cases and it's a
good thing to have them. Note that they can be applied not only to cache
keys, but to any binary objects.

Hibernate issue is actually a good example of such use case. The fact that
we found an alternative solution doesn't actually mean anything, because
what if this happened not in our module, but in user's application?
Unfortunately, we can't predict everything.

Error proneness is not a very strong argument either, because in my view
these resolvers are as much error prone as BinaryIdMapper, for example.

-Val

On Wed, Apr 5, 2017 at 11:44 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Denis,
>
> Can you suggest a use-case where identity resolver is needed (given that we
> agree that a key must contain only valuable fields)?
>
> 2017-04-05 22:08 GMT+03:00 Denis Magda <dma...@apache.org>:
>
> > Where do you want to remove the identity resolvers from? If it’s related
> > to the internals of Hibernate module then it’s fine but if you suggest
> > removing identity resolvers public interfaces then it might be a haste
> > decision.
> >
> > —
> > Denis
> >
> > > On Apr 5, 2017, at 7:42 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com>
> > wrote:
> > >
> > > +1, I see no other reasons to keep it.
> > >
> > > 2017-04-05 13:59 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>:
> > >
> > >> +1
> > >>
> > >> Lets drop them.
> > >>
> > >> Sergi
> > >>
> > >> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
> > >> dmitriy.govoruk...@gmail.com>
> > >> :
> > >>
> > >>> Hi guys, i implemented proxy for IgniteCache in hibernate
> integration,
> > >> this
> > >>> proxy transformate cacheKey to our key wrapper, leaves only required
> > >>> field. I think we can remove identity resolve, it should not broke
> > >>> integration with hibernate. Any objections?
> > >>>
> > >>> On Wed, Mar 29, 2017 at 11:07 PM, Valentin Kulichenko <
> > >>> valentin.kuliche...@gmail.com> wrote:
> > >>>
> > >>>> I'm not saying there is no alternative solution. But let's implement
> > it
> > >>> and
> > >>>> prove that it works first, and remove resolvers only after that.
> > >>>>
> > >>>> -Val
> > >>>>
> > >>>> On Wed, Mar 29, 2017 at 12:18 PM, Sergi Vladykin <
> > >>> sergi.vlady...@gmail.com
> > >>>>>
> > >>>> wrote:
> > >>>>
> > >>>>> Guys, nothing is impossible if you know a bit about reflection in
> > >> Java
> > >>> :)
> > >>>>>
> > >>>>> We had a look at the CacheKey class and it is easily replaceable.
> > >>>>>
> > >>>>> Sergi
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> 2017-03-29 21:49 GMT+03:00 Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >>> :
> > >>>>>
> > >>>>>> On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> > >>>>>> valentin.kuliche...@gmail.com> wrote:
> > >>>>>>
> > >>>>>>> "Hibernate key" is the CacheKey class I was referring to. It's
> > >>>> provided
> > >>>>>> by
> > >>>>>>> Hibernate, not by user and not by us. So I'm not sure it's
> > >> possible
> > >>>> to
> > >>>>>>> replace it.
> > >>>>>>>
> > >>>>>>
> > >>>>>> If it is impossible to replace or get rid of the Hibernate key, is
> > >>> this
> > >>>>>> discussion valid at all?
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

Reply via email to