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 <dma...@apache.org> wrote: > 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 any other reason why we can’t leverage from them in our code in order > to fix the mentioned Hibernate bug. > > — > Denis > > > On Mar 29, 2017, at 10:38 AM, Sergi Vladykin <sergi.vlady...@gmail.com> > wrote: > > > > 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 <alexey.goncha...@gmail.com > >: > > > >> Guys, > >> > >> I stumbled across this ticket [1] and it seems to me that the whole > >> approach of identity resolvers is error-prone. If a key contains some > data > >> that does not participate in equals() calculation, these fields may be > as > >> well moved to the value object. Even with binary objects, key mutation > >> looks like an error-prone approach. > >> > >> I suggest we remove identity resolver in Ignite 2.0 and ask a user to > >> provide a correct implementation of a key. For the Hibernate > integration, I > >> think a correct fix would be to replace the Hibernate key with another > >> correct key class. > >> > >> Thoughts? > >> > >> [1] https://issues.apache.org/jira/browse/IGNITE-3429 > >> > >
