Denis, I think it is important that we know which specific field to use for the affinity resolution, but I don't see any issue in using both, primary and foreign keys, for hashcode and equality. Do you?
D. On Tue, Apr 11, 2017 at 11:46 AM, Igor Sapego <isap...@apache.org> wrote: > Denis, > > The whole binary representation of the object is used now > for hash code generation and equality comparison. So the > answer - all fields are used for this. > > Best Regards, > Igor > > On Mon, Apr 10, 2017 at 9:50 PM, Denis Magda <dma...@apache.org> wrote: > > > Considering this simple example > > > > INSERT (id, orgId, name, age, address) into Person… > > > > where id and orgId define Person’s affinity key - PersonKey(id, orgId) > > > > How do we know which fields to use for hash code generation and equality > > comparison? QueryEntity? > > > > No, it’s unclear how to document it properly. > > > > — > > Denis > > > > > On Apr 10, 2017, at 11:14 AM, Vladimir Ozerov <voze...@gridgain.com> > > wrote: > > > > > > There is no more such resolver. It was removed. > > > > > > On Mon, Apr 10, 2017 at 8:58 PM, Denis Magda <dma...@apache.org> > wrote: > > > > > >> Vovan, > > >> > > >> Before I fix the documentation, what’t the replacement for > > >> BinaryFieldIdentiyResolver we used to define field for hash code > > >> calculation and equality comparison when DML statements are used? > > >> https://apacheignite.readme.io/docs/binary-marshaller# > > >> section-binary-field-identity-resolver <https://apacheignite.readme. > > >> io/docs/binary-marshaller#section-binary-field-identity-resolver> > > >> > > >> — > > >> Denis > > >> > > >>> On Apr 9, 2017, at 7:39 AM, Vladimir Ozerov <voze...@gridgain.com> > > >> wrote: > > >>> > > >>> Resolvers were essential for DML because we had broken comparison > > >> semantics > > >>> of binary objects. This is not the case now. > > >>> > > >>> Resolver as a whole is normal practice. E.g. it is implemented in > .NET > > on > > >>> core language level and widely used in many cases. Hazelcast has it > as > > >> well > > >>> AFAIK. So it is wrong to think that the whole idea is useless. Think > of > > >> it > > >>> as a comparator's brother. > > >>> > > >>> The only reason why we need to remove it is missing hash index in new > > >>> architecture. It makes sense, as it is better to have AI 2.0 without > > >> them, > > >>> than no AI 2.0 :-) > > >>> > > >>> 09 апр. 2017 г. 17:31 пользователь "Sergi Vladykin" < > > >>> sergi.vlady...@gmail.com> написал: > > >>> > > >>>> I guess Resolvers were added to DML just because they already > existed > > >> since > > >>>> 1.9 and we were forced to support them in all the parts of our > > product. > > >>>> > > >>>> We have to stop this practice to add features without clear real > life > > >> use > > >>>> cases for them. > > >>>> > > >>>> Sergi > > >>>> > > >>>> 2017-04-09 17:00 GMT+03:00 Denis Magda <dma...@gridgain.com>: > > >>>> > > >>>>> Sergi, Vovan, > > >>>>> > > >>>>> Sorry for being annoying but I still didn't get an answer on > whether > > >> the > > >>>>> resolvers are the must for DML. The main reason why we made them up > > >> some > > >>>>> time ago is to support specific DML use cases. However I can't > recall > > >> the > > >>>>> use cases. > > >>>>> > > >>>>> -- > > >>>>> Denis > > >>>>> > > >>>>> On Sun, Apr 9, 2017 at 6:54 AM, Sergi Vladykin < > > >> sergi.vlady...@gmail.com > > >>>>> > > >>>>> wrote: > > >>>>> > > >>>>>> Ok, we need to do 2 things here: > > >>>>>> > > >>>>>> 1. Drop the resolvers from the source code. > > >>>>>> 2. Write a good page in docs on "What makes a correct cache key". > > >>>>>> > > >>>>>> Who can do that? > > >>>>>> > > >>>>>> Sergi > > >>>>>> > > >>>>>> 2017-04-07 9:48 GMT+03:00 Sergi Vladykin < > sergi.vlady...@gmail.com > > >: > > >>>>>> > > >>>>>>> It is possible to try adding support of comparison to Resolvers, > > but > > >>>>> the > > >>>>>>> whole approach looks wrong and for now it is better to get rid of > > it > > >>>>>> while > > >>>>>>> we have a chance to break compatibility. > > >>>>>>> > > >>>>>>> Sergi > > >>>>>>> > > >>>>>>> 2017-04-07 9:19 GMT+03:00 Valentin Kulichenko < > > >>>>>>> valentin.kuliche...@gmail.com>: > > >>>>>>> > > >>>>>>>> The discussion should've been started with that :) If supporting > > >>>>>> resolvers > > >>>>>>>> in new architecture is not possible or means too big effort, > then > > >>>> it's > > >>>>>>>> definitely not worth it. > > >>>>>>>> > > >>>>>>>> -Val > > >>>>>>>> > > >>>>>>>> On Thu, Apr 6, 2017 at 8:52 PM, Vladimir Ozerov < > > >>>> voze...@gridgain.com > > >>>>>> > > >>>>>>>> wrote: > > >>>>>>>> > > >>>>>>>>> Dima, > > >>>>>>>>> > > >>>>>>>>> Yes, they may explode some internals of our indexes. > > >>>>>>>>> > > >>>>>>>>> 06 апр. 2017 г. 23:32 пользователь "Dmitriy Setrakyan" < > > >>>>>>>>> dsetrak...@apache.org> написал: > > >>>>>>>>> > > >>>>>>>>>> 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? > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >> > > >> > > > > >
