Andrey, do you have a specific unit test which shows the issue? Can you check if this is still applicable?
To my knowledge, Hibernate integration was reworked in 2.0 so that we never put Hibernate keys to cache but instead we create our own correct keys which guarantee required keys properties. 2017-04-19 4:46 GMT+03:00 Andrey Mashenkov <andrey.mashen...@gmail.com>: > Denis, I'll rework PR according new solution. > > Alex G, Sergi, what approach is used for keys comparison in ignite 2.0 ? > > On Tue, Apr 18, 2017 at 11:11 PM, Denis Magda <dma...@apache.org> wrote: > > > At all, guys, BinaryIdentityResolvers were discontinued but the ticket > [1] > > that had triggered the discussion has not been fixed yet. > > > > It must be fixed in 2.0 otherwise Hibernate integration can be considered > > broken in 2.0 because the initial workaround was based on the resolvers. > > > > Andrey M., will you finalize it. Alex G. and Sergi can suggest > > non-resolvers based solution. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-3429 < > > https://issues.apache.org/jira/browse/IGNITE-3429> > > > > — > > Denis > > > > > On Apr 11, 2017, at 12:06 PM, Denis Magda <dma...@apache.org> wrote: > > > > > > I don’t see either unless a key’s field is of a float type. However, it > > sounds like an artificial use case. > > > > > > Thanks for the details. > > > > > > — > > > Denis > > > > > >> On Apr 11, 2017, at 11:50 AM, Dmitriy Setrakyan < > dsetrak...@apache.org> > > wrote: > > >> > > >> 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? > > >>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>>>> > > >>>> > > >>>> > > >>> > > > > > > > > > > -- > Best regards, > Andrey V. Mashenkov >
