ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: Stable binary key representation
Date Thu, 06 Apr 2017 11:24:18 GMT
Even with my vast expirience I would never claim that I've seen
"everything" :)

What do you mean by stable binary key representation and how resolvers make
it unstable?

-Val

On Thu, Apr 6, 2017 at 2:36 AM, Sergi Vladykin <sergi.vladykin@gmail.com>
wrote:

> Val,
>
> I know that you have really vast experience in Ignite deployments and
> probably saw everything that can happen. Did you ever see identity
> resolvers use in real life? I guess no.
>
> Hibernate example is bad here, because if their key is unstable across
> multiple JVMs, it means that it was not designed for distributed caches a
> priori.
>
> Also knowing in advance about stable binary key representation allows us to
> apply additional optimizations, like comparing keys without detaching them
> from offheap memory.
>
> We always will be able to add this stuff back if we see users really need
> it. Let's remove it for 2.0.
>
> Sergi
>
> 2017-04-06 11:21 GMT+03:00 Valentin Kulichenko <
> valentin.kulichenko@gmail.com>:
>
> > 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.goncharuk@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 <dmagda@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.goncharuk@gmail.com>
> > > > wrote:
> > > > >
> > > > > +1, I see no other reasons to keep it.
> > > > >
> > > > > 2017-04-05 13:59 GMT+03:00 Sergi Vladykin <
> sergi.vladykin@gmail.com
> > >:
> > > > >
> > > > >> +1
> > > > >>
> > > > >> Lets drop them.
> > > > >>
> > > > >> Sergi
> > > > >>
> > > > >> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
> > > > >> dmitriy.govorukhin@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.kulichenko@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.vladykin@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 <
> > > dsetrakyan@apache.org
> > > > >>> :
> > > > >>>>>
> > > > >>>>>> On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko
<
> > > > >>>>>> valentin.kulichenko@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?
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message