> > > >> >>> Good point, however, currently there's no way to
> > > > > distinguish
> > > > > > > > hash
> > > > > > > > > > code
> > > > > > > > > > >> >>> of
gt; >> >>> - Alex
> > > > > > > > > >> >>>
> > > > > > > > > >> >>> 2016-08-02 9:47 GMT+03:00 Dmitriy Setrakyan <
> > > > > > > > dsetrak...@apache.org
> > > > >
wrote:
> > > > > > > > >> >>>>
> > > > > > > > >> >>>>> Andrey,
> > > > > > > > >> >>>>>
> > > > > > > > >> >>>>> The question is whe
. I doubt we
> > can
> > > > > > print a
> > > > > > > >> >> warning
> > > > > > > >> >>>>> when calling *BinaryObjectBuilder.build() *method,
> > because
> > > > an
> > > > > > > object
> > > > > > > >> >>>&
; > > >> >>>> hashCode ends up on a put or read operation in cache.
> > > > > > >> >>>>
> > > > > > >> >>>>
> > > > > > >> >>>>> On Tue, Aug 2, 201
; >>>>>> I think we also should print some warning in case when
> > > > hashCode()
> > > > > >> >> wasn't
> > > > > >> >>>>>> called on BinaryObject e
, Aug 2, 2016 at 2:20 AM, Dmitriy Setrakyan <
> > > > >> >> dsetrak...@apache.org
> > > > >> >>>>>>
> > > > >> >>>>>> wrote:
> > > > >> >>>>>>
> >
t; >> >>>>>>> On Mon, Aug 1, 2016 at 10:01 AM, Alexey Goncharuk <
> > > >> >>>>>>> alexey.goncha...@gmail.com> wrote:
> > > >> >>>>>>>
> > > >> >>>>>>>> Dmitriy,
> > > >> >>>>>>>>
> &
> > >> >>>>>>> want
> > >> >>>>>>>> it to be specified explicitly in INSERT statement?
> > >> >>>>>>>>
> > >> >&g
tionally we should allow to specify hashCode as part
> of
> >> the
> >> >>>>>>> INSERT statement. However, if it is not specified, we should
> >> >> calculate
> >> >>>>> it
gt; >>>>>>>
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>> 2016-08-01 19:47 GMT+03:00 Dmitriy Setrakyan <
>> dsetrak...@apache.org
>> >>>>>> :
>> >>>>>&
t;>>
> >>>>>>>>
> >>>>>>>> 2016-08-01 19:47 GMT+03:00 Dmitriy Setrakyan <
> dsetrak...@apache.org
> >>>>>> :
> >>>>>>>>
> >>>>>>>>> Alex,
> >>>>>>>>>
gt;>>>>>>
>>>>>>>>> In your case, why not just explicitly set hashcode every time you
>>>>>>> create
>>>>>>>> an
>>>>>>>>> object? There is BinaryObjectBuilder.hashCode(...) method.
>>>>>>&
>>> D.
> >>>>>>>
> >>>>>>> On Mon, Aug 1, 2016 at 7:42 AM, al.psc <
> >>>>> alexander.a.pasche...@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
gt;>>>
>>>>>>>> It seems like this problem has become an important one once
>>> again.
>>>>>>>> In the course of working on
>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-2294 (DML support)
>>&g
t; > >
> >> > > > > > Guys,
> >> > > > > >
> >> > > > > > It seems like this problem has become an important one once
> >> again.
> >> > > > > > In the course of working on
> >> > > > > > https://issues.apache.org/jira/browse/IGNITE-2294 (
gt; and put it to cache, without adequate hash code it won't be stored
>> > > > properly.
>> > > > Currently SQL MERGE works simply by deserializing newly built object,
>> > but
>> > > > it's obviously wrong and is just a workaround rather a solution.
>> > > > Has anyone come with possible design proposals for this problem's
>> > > solution?
>> > > >
>> > > > Thanks.
>> > > >
>> > > > - Alex
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > View this message in context:
>> > > >
>> > >
>> >
>> http://apache-ignite-developers.2346864.n4.nabble.com/All-BinaryObjects-created-by-BinaryObjectBuilder-stored-at-the-same-partition-by-default-tp8042p10304.html
>> > > > Sent from the Apache Ignite Developers mailing list archive at
>> > > Nabble.com.
>> > > >
>> > >
>> >
>>
; > Currently SQL MERGE works simply by deserializing newly built object,
> > but
> > > > it's obviously wrong and is just a workaround rather a solution.
> > > > Has anyone come with possible design proposals for this problem's
> > > solution?
> > > >
> > > > Thanks.
> > > >
> > > > - Alex
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/All-BinaryObjects-created-by-BinaryObjectBuilder-stored-at-the-same-partition-by-default-tp8042p10304.html
> > > > Sent from the Apache Ignite Developers mailing list archive at
> > > Nabble.com.
> > > >
> > >
> >
>
; > > > > > to support binary marshaller. And, although we can build just
>> > > > > BinaryObject
>> > > > > > and put it to cache, without adequate hash code it won't be
>> stored
>> > > > > > properly.
>> > > > > > Currently SQL MERGE works simply by deserializing newly built
>> > object,
>> > > > but
>> > > > > > it's obviously wrong and is just a workaround rather a solution.
>> > > > > > Has anyone come with possible design proposals for this problem's
>> > > > > solution?
>> > > > > >
>> > > > > > Thanks.
>> > > > > >
>> > > > > > - Alex
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > View this message in context:
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://apache-ignite-developers.2346864.n4.nabble.com/All-BinaryObjects-created-by-BinaryObjectBuilder-stored-at-the-same-partition-by-default-tp8042p10304.html
>> > > > > > Sent from the Apache Ignite Developers mailing list archive at
>> > > > > Nabble.com.
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Andrey Gura
>> > GridGain Systems, Inc.
>> > www.gridgain.com
>> >
>>
294 (DML support)
> > > > there's
> > > > > > need
> > > > > > to support binary marshaller. And, although we can build just
> > > > > BinaryObject
> > > > > > and put it to cache, without adequate hash code it won't be
> stored
gt; > > BinaryObject
> > > > > and put it to cache, without adequate hash code it won't be stored
> > > > > properly.
> > > > > Currently SQL MERGE works simply by deserializing newly built
> object,
> > > but
> > > > > it's obviously
GE works simply by deserializing newly built object,
> > but
> > > > it's obviously wrong and is just a workaround rather a solution.
> > > > Has anyone come with possible design proposals for this problem's
> > > solution?
> > > >
> > > > Thanks
tion.
> > > Has anyone come with possible design proposals for this problem's
> > solution?
> > >
> > > Thanks.
> > >
> > > - Alex
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/All-BinaryObjects-created-by-BinaryObjectBuilder-stored-at-the-same-partition-by-default-tp8042p10304.html
> > > Sent from the Apache Ignite Developers mailing list archive at
> > Nabble.com.
> > >
> >
>
works simply by deserializing newly built object, but
> > it's obviously wrong and is just a workaround rather a solution.
> > Has anyone come with possible design proposals for this problem's
> solution?
> >
> > Thanks.
> >
> > - Alex
> >
> >
his message in context:
> http://apache-ignite-developers.2346864.n4.nabble.com/All-BinaryObjects-created-by-BinaryObjectBuilder-stored-at-the-same-partition-by-default-tp8042p10304.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>
s message in context:
http://apache-ignite-developers.2346864.n4.nabble.com/All-BinaryObjects-created-by-BinaryObjectBuilder-stored-at-the-same-partition-by-default-tp8042p10304.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
naryObjects created by BinaryObjectBuilder stored at the
> same partition by default
> From: akuznet...@gridgain.com
> To: dev@ignite.apache.org
>
> As for JdbcPojoStore it has an option to configure "hasher".
>
> On Thu, Mar 24, 2016 at 5:20 PM, Denis Magda wrote
naryObjects created by BinaryObjectBuilder stored at the
> same partition by default
> From: akuznet...@gridgain.com
> To: dev@ignite.apache.org
>
> As for JdbcPojoStore it has an option to configure "hasher".
>
> On Thu, Mar 24, 2016 at 5:20 PM, Denis Magda wrote
As for JdbcPojoStore it has an option to configure "hasher".
On Thu, Mar 24, 2016 at 5:20 PM, Denis Magda wrote:
> +1 for the improvement of JavaDoc because the problem arises only when
> BinaryObjects are used as keys.
> Readme.io already has a warning regarding this
>
> https://apacheignite.re
+1 for the improvement of JavaDoc because the problem arises only when
BinaryObjects are used as keys.
Readme.io already has a warning regarding this
https://apacheignite.readme.io/docs/binary-marshaller#modifying-binary-objects-using-binaryobjectbuilder
--
Denis
On 3/24/2016 12:38 PM, Vladimir
When object has been built, there is no way to know, whether hash code was
set or not. Zero could be real hash code, as well as not set hash code.
Random is not an option. Any kind of automatic generation is not an option
as well, because we do not know, how hash code of real class instance is
cal
Random hash code is not an option.
I would suggest cache throws exception on update if binary object created
with builder does not have hash code initialized.
Vladimir, can we somehow make it possible to know whether hash code was or
was not inited on a binary object?
--Yakov
2016-03-24 11:43 G
Hello,
I found that every BinaryObject created by BinaryObjectBuilder has hashcode
== 0 by default.
This can cause situation that all objects created by code similar to:
*BinaryObject key = builder.setField("id", i).build();*
*streamer.addData(key, key);*
will be stored at one partition and this
33 matches
Mail list logo
