t;>>>>>>>>
>>>>>>>>>>>>>>> The discussion should've been started with that :) If
>>> supporting
>>>>>>>>>>>>> resolvers
>>>>>>>>>>&
gt;> Sergi
> > >>>>>>>>>>>
> > >>>>>>>>>>> 2017-04-07 9:19 GMT+03:00 Valentin Kulichenko <
> > >>>>>>>>>>> valentin.kuliche...@gmail.com>:
> > >>>>>>>>>>>
> > >
.kuliche...@gmail.com>:
> >>>>>>>>>>>
> >>>>>>>>>>>> The discussion should've been started with that :) If
> supporting
> >>>>>>>>>> resolvers
> >>>>>>>>&
>>>>>>>>>>>> definitely not worth it.
>>>>>>>>>>>>
>>>>>>>>>>>> -Val
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Apr 6, 2017 at
dimir Ozerov <
>>>>>>> voze...@gridgain.com
>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Dima,
>>>>>>>>>>>
>>>>>>>>
> > >>>>>>>>>> Guys,
> > >>>>>>>>>>
> > >>>>>>>>>> Isn't the main issue here that we cannot use the Identity
> > >>>>> Resolvers
>
;>>> 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 <
gt; Binary key representation is stable when we always have equal
> >>>>>>> serialized
> >>>>>>>>> bytes when the original keys are equal.
> >>>>>>>>>
> >>>>>>>>> Resolver allows you to
>>>>>>>>> bytes when the original keys are equal.
>>>>>>>>>
>>>>>>>>> Resolver allows you to have some extra info in the Key and
>> equal
>>>>>> Keys
>>>>>>>> will
>>>>>
> > >> > > 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
> > (b
.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
> >>
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 i
t; > > 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
> >
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...
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-0
t;
> > 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
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 vast
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 v
cross
> 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.
>
>
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&#
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 ex
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 Hibernate module then
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
> wrote:
>
>
+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 integration,
> this
> > pro
+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 resolve, it should not broke
> i
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
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 in Java :)
>
> We had a look
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 <
> valentin.kuliche...@gmail.com> wrote:
>
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
"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 "Hibernate key" and what is a "
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 <
alexey.goncha...@gmail.
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 DML. *Vovan*, *Alex P
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
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 across this ticket [1] and it seem
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
look
37 matches
Mail list logo
