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
