Stable binary key representation

[Alexey Goncharuk]

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

[Sergi]

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 <[hidden email]>:

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

[dmagda]

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 <[hidden email]> 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 <[hidden email]>:
>
>> 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
>>

[Valentin Kulichenko]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]
> >:
> >
> >> 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
> >>
>
>

[dsetrakyan]

Alexey,

Can you explain what is the "Hibernate key" and what is a "correct key
class"? Are you suggesting that currently we don't require our users
interested in Hibernate integration to provide a "correct key class"?

D.

On Wed, Mar 29, 2017 at 9:08 AM, Alexey Goncharuk <
[hidden email]> wrote:

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

[Valentin Kulichenko]

"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 <[hidden email]>
wrote:

> Alexey,
>
> Can you explain what is the "Hibernate key" and what is a "correct key
> class"? Are you suggesting that currently we don't require our users
> interested in Hibernate integration to provide a "correct key class"?
>
> D.
>
> On Wed, Mar 29, 2017 at 9:08 AM, Alexey Goncharuk <
> [hidden email]> wrote:
>
> > 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
> >
>

[dsetrakyan]

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

[Sergi]

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 <[hidden email]>:

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

[Valentin Kulichenko]

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

[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 resolve, it should not broke
integration with hibernate. Any objections?

On Wed, Mar 29, 2017 at 11:07 PM, Valentin Kulichenko <
[hidden email]> 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 <[hidden email]
> >
> 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 <[hidden email]>:
> >
> > > On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> > > [hidden email]> 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?
> > >
> >
>

[Sergi]

+1

Lets drop them.

Sergi

2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <[hidden email]>
:

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

[Alexey Goncharuk]

+1, I see no other reasons to keep it.

2017-04-05 13:59 GMT+03:00 Sergi Vladykin <[hidden email]>:

> +1
>
> Lets drop them.
>
> Sergi
>
> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
> [hidden email]>
> :
>
> > 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 <
> > [hidden email]> 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 <
> > [hidden email]
> > > >
> > > 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 <[hidden email]
> >:
> > > >
> > > > > On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> > > > > [hidden email]> 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?
> > > > >
> > > >
> > >
> >
>

[dmagda]

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 <[hidden email]> wrote:
>
> +1, I see no other reasons to keep it.
>
> 2017-04-05 13:59 GMT+03:00 Sergi Vladykin <[hidden email]>:
>
>> +1
>>
>> Lets drop them.
>>
>> Sergi
>>
>> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
>> [hidden email]>
>> :
>>
>>> 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 <
>>> [hidden email]> 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 <
>>> [hidden email]
>>>>>
>>>> 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 <[hidden email]
>>> :
>>>>>
>>>>>> On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
>>>>>> [hidden email]> 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?
>>>>>>
>>>>>
>>>>
>>>
>>

[Alexey Goncharuk]

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 <[hidden email]>:

> 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 <[hidden email]>
> wrote:
> >
> > +1, I see no other reasons to keep it.
> >
> > 2017-04-05 13:59 GMT+03:00 Sergi Vladykin <[hidden email]>:
> >
> >> +1
> >>
> >> Lets drop them.
> >>
> >> Sergi
> >>
> >> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
> >> [hidden email]>
> >> :
> >>
> >>> 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 <
> >>> [hidden email]> 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 <
> >>> [hidden email]
> >>>>>
> >>>> 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 <[hidden email]
> >>> :
> >>>>>
> >>>>>> On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> >>>>>> [hidden email]> 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?
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

[Valentin Kulichenko]

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 <
[hidden email]> 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 <[hidden email]>:
>
> > 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 <
> [hidden email]>
> > wrote:
> > >
> > > +1, I see no other reasons to keep it.
> > >
> > > 2017-04-05 13:59 GMT+03:00 Sergi Vladykin <[hidden email]>:
> > >
> > >> +1
> > >>
> > >> Lets drop them.
> > >>
> > >> Sergi
> > >>
> > >> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
> > >> [hidden email]>
> > >> :
> > >>
> > >>> 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 <
> > >>> [hidden email]> 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 <
> > >>> [hidden email]
> > >>>>>
> > >>>> 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 <
> [hidden email]
> > >>> :
> > >>>>>
> > >>>>>> On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> > >>>>>> [hidden email]> 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?
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

[Sergi]

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 <
[hidden email]>:

> 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 <
> [hidden email]> 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 <[hidden email]>:
> >
> > > 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 <
> > [hidden email]>
> > > wrote:
> > > >
> > > > +1, I see no other reasons to keep it.
> > > >
> > > > 2017-04-05 13:59 GMT+03:00 Sergi Vladykin <[hidden email]
> >:
> > > >
> > > >> +1
> > > >>
> > > >> Lets drop them.
> > > >>
> > > >> Sergi
> > > >>
> > > >> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
> > > >> [hidden email]>
> > > >> :
> > > >>
> > > >>> 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 <
> > > >>> [hidden email]> 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 <
> > > >>> [hidden email]
> > > >>>>>
> > > >>>> 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 <
> > [hidden email]
> > > >>> :
> > > >>>>>
> > > >>>>>> On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> > > >>>>>> [hidden email]> 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?
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>

[Denis Magda]

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 <[hidden email]> 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 <
> [hidden email] <javascript:;>>:
>
> > 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 <
> > [hidden email] <javascript:;>> 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 <[hidden email]
> <javascript:;>>:
> > >
> > > > 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 <
> > > [hidden email] <javascript:;>>
> > > > wrote:
> > > > >
> > > > > +1, I see no other reasons to keep it.
> > > > >
> > > > > 2017-04-05 13:59 GMT+03:00 Sergi Vladykin <
> [hidden email] <javascript:;>
> > >:
> > > > >
> > > > >> +1
> > > > >>
> > > > >> Lets drop them.
> > > > >>
> > > > >> Sergi
> > > > >>
> > > > >> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
> > > > >> [hidden email] <javascript:;>>
> > > > >> :
> > > > >>
> > > > >>> 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 <
> > > > >>> [hidden email] <javascript:;>> 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 <
> > > > >>> [hidden email] <javascript:;>
> > > > >>>>>
> > > > >>>> 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 <
> > > [hidden email] <javascript:;>
> > > > >>> :
> > > > >>>>>
> > > > >>>>>> On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> > > > >>>>>> [hidden email] <javascript:;>> 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?
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>

[Valentin Kulichenko]

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 <[hidden email]>
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 <
> [hidden email]>:
>
> > 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 <
> > [hidden email]> 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 <[hidden email]>:
> > >
> > > > 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 <
> > > [hidden email]>
> > > > wrote:
> > > > >
> > > > > +1, I see no other reasons to keep it.
> > > > >
> > > > > 2017-04-05 13:59 GMT+03:00 Sergi Vladykin <
> [hidden email]
> > >:
> > > > >
> > > > >> +1
> > > > >>
> > > > >> Lets drop them.
> > > > >>
> > > > >> Sergi
> > > > >>
> > > > >> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
> > > > >> [hidden email]>
> > > > >> :
> > > > >>
> > > > >>> 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 <
> > > > >>> [hidden email]> 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 <
> > > > >>> [hidden email]
> > > > >>>>>
> > > > >>>> 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 <
> > > [hidden email]
> > > > >>> :
> > > > >>>>>
> > > > >>>>>> On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> > > > >>>>>> [hidden email]> 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?
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>

[Sergi]

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 <
[hidden email]>:

> 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 <[hidden email]>
> 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 <
> > [hidden email]>:
> >
> > > 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 <
> > > [hidden email]> 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 <[hidden email]>:
> > > >
> > > > > 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 <
> > > > [hidden email]>
> > > > > wrote:
> > > > > >
> > > > > > +1, I see no other reasons to keep it.
> > > > > >
> > > > > > 2017-04-05 13:59 GMT+03:00 Sergi Vladykin <
> > [hidden email]
> > > >:
> > > > > >
> > > > > >> +1
> > > > > >>
> > > > > >> Lets drop them.
> > > > > >>
> > > > > >> Sergi
> > > > > >>
> > > > > >> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
> > > > > >> [hidden email]>
> > > > > >> :
> > > > > >>
> > > > > >>> 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 <
> > > > > >>> [hidden email]> 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 <
> > > > > >>> [hidden email]
> > > > > >>>>>
> > > > > >>>> 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 <
> > > > [hidden email]
> > > > > >>> :
> > > > > >>>>>
> > > > > >>>>>> On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> > > > > >>>>>> [hidden email]> 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?
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

[dsetrakyan]

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 <[hidden email]>
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 <
> [hidden email]>:
>
> > 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 <[hidden email]
> >
> > 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 <
> > > [hidden email]>:
> > >
> > > > 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 <
> > > > [hidden email]> 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 <[hidden email]>:
> > > > >
> > > > > > 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 <
> > > > > [hidden email]>
> > > > > > wrote:
> > > > > > >
> > > > > > > +1, I see no other reasons to keep it.
> > > > > > >
> > > > > > > 2017-04-05 13:59 GMT+03:00 Sergi Vladykin <
> > > [hidden email]
> > > > >:
> > > > > > >
> > > > > > >> +1
> > > > > > >>
> > > > > > >> Lets drop them.
> > > > > > >>
> > > > > > >> Sergi
> > > > > > >>
> > > > > > >> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
> > > > > > >> [hidden email]>
> > > > > > >> :
> > > > > > >>
> > > > > > >>> 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 <
> > > > > > >>> [hidden email]> 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 <
> > > > > > >>> [hidden email]
> > > > > > >>>>>
> > > > > > >>>> 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 <
> > > > > [hidden email]
> > > > > > >>> :
> > > > > > >>>>>
> > > > > > >>>>>> On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> > > > > > >>>>>> [hidden email]> 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?
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>