Re: Stable binary key representation

Guys, if this is true > 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. then who did this? Referring to the discussion in the ticket I’m not sure about

Re: Stable binary key representation

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.

Re: Stable binary key representation

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 wrote: > At all, guys, BinaryIdentityResolvers were discontinued but the ticket [1] > that had triggered the

Re: Stable binary key representation

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.,

Re: Stable binary key representation

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 wrote: > > Denis, I think it is important that we know which specific field to

Re: Stable binary key representation

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 wrote: > Denis, > >

Re: Stable binary key representation

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 wrote: > Considering this simple example > >

Re: Stable binary key representation

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

Re: Stable binary key representation

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

Re: Stable binary key representation

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

Re: Stable binary key representation

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

Re: Stable binary key representation

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 : > It is possible to try adding support of comparison to

Re: Stable binary key representation

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 : > The discussion

Re: Stable binary key representation

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 wrote: > Dima, > > Yes, they may explode some

Re: Stable binary key representation

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

Re: Stable binary key representation

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 wrote: > Binary key representation is stable when we always

Re: Stable binary key representation

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

Re: Stable binary key representation

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 wrote: > Val, > > I know that you have really

Re: Stable binary key representation

It's reasonable to listen to Vladimir Ozerov and Alex Paschenko opinion before any removal. The identity resolvers were designed by them for specific use cases and, if I'm not mistaken, one is DML related. Folks, please join the conversation. Denis On Thursday, April 6, 2017, Sergi Vladykin

Re: Stable binary key representation

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

Re: Stable binary key representation

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

Re: Stable binary key representation

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 : > Where do you want to remove the identity resolvers from? If it’s related > to the internals of

Re: Stable binary key representation

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

Re: Stable binary key representation

+1, I see no other reasons to keep it. 2017-04-05 13:59 GMT+03:00 Sergi Vladykin : > +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

Re: Stable binary key representation

+1 Lets drop them. Sergi 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin : > 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

Re: Stable binary key representation

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,

Re: Stable binary key representation

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 wrote: > Guys, nothing is impossible if you know a bit about reflection

Re: Stable binary key representation

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 : > On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko < >

Re: Stable binary key representation

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

Re: Stable binary key representation

"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. -Val On Wed, Mar 29, 2017 at 11:36 AM, Dmitriy Setrakyan wrote: > Alexey, > > Can you explain what is the

Re: Stable binary key representation

Alex, How do you suggest to replace the CacheKey class? It's internal for Hibernate and I'm not sure it's possible. -Val On Wed, Mar 29, 2017 at 11:09 AM, Denis Magda wrote: > I’m not sure we can simply discontinue the identity resolvers that were > originally created for

Re: Stable binary key representation

I’m not sure we can simply discontinue the identity resolvers that were originally created for DML. *Vovan*, *Alex Paschenko*, please chime in and provide your thoughts. Don’t want us to make such decisions in haste. Alex G., in any case, assuming that the resolvers are still in 2.0 is there

Re: Stable binary key representation

It looks like a good idea to drop identity resolvers for now and require stable binary representation for keys in 2.0. Later if it will be really needed we will be able to add them back. Sergi 2017-03-29 19:08 GMT+03:00 Alexey Goncharuk : > Guys, > > I stumbled