Guys, Isn't the main issue here that we cannot use the Identity Resolvers in BTrees in the 2.0 version? If yes, then we have to remove them no matter what.
D. On Thu, Apr 6, 2017 at 1:23 PM, Sergi Vladykin <sergi.vlady...@gmail.com> wrote: > Binary key representation is stable when we always have equal serialized > bytes when the original keys are equal. > > Resolver allows you to have some extra info in the Key and equal Keys will > be serialized into different bytes, which is wrong. > > Look at the example what you can do with resolvers: > > We may have some data entry with fields a, b, c. Let's say the unique part > here is `a` and it the only fields used in Key equals() and hashCode(). > Still we may have the following layouts: > > 1. Ka -> Vbc > 2. Kab -> Vc > 3. Kabc -> Boolean.TRUE > > The only 1 is a correct layout, others are plain wrong variants (but they > are still possible with Resolvers) because everything that does not make > Key unique must be in Value. > > We want to clearly state that if you have something in Key, that is not > part of equals(), then the Key is invalid and that stuff must be in Value. > This allows us to rely on binary representation of a Key to be stable and > have some more optimizations and code simplifications with respect to these > assumptions. > > Sergi > > 2017-04-06 14:24 GMT+03:00 Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > > > 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.vlady...@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.kuliche...@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.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? > > > > > > >>>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >
