Vova, By default hasCode field will be initialized this way in BinaryObjectBuilderImpl
/** */ private static Integer DFLT_HASH_CODE_MAGIC = 0; /** */ private Integer hashCode = DFLT_HASH_CODE_MAGIC; Also we will introduce the following flag in BinaryUtils /** Flag indicating whether as hashCode was explicitly set or not. **/ public static final short EMPTY_HASH_CODE_FLAG = 0x0032; At the BinaryObjectBuilder.build() time we will perform the check below and write hashCodeFlag. short hashCodeFlag = hashCode == DFLT_HASH_CODE_MAGIC ? BinaryUtils.EMPTY_HASH_CODE_FLAG : 0; // Write hashCode flag as well. writer.postWrite(true, registeredType, hashCode, hashCodeFlag); Later when a BinaryObject is used as a key we can check the value of BinaryUtils.EMPTY_HASH_CODE_FLAG and throw an exception if it’s not empty. Makes sense? — Denis > On Aug 2, 2016, at 7:09 AM, Vladimir Ozerov <voze...@gridgain.com> wrote: > > Denis, > > I hardly can imagine how it could work in our binary protocol. Can you > please elaborate? > > On Tue, Aug 2, 2016 at 5:06 PM, Denis Magda <dma...@gridgain.com> wrote: > >> There is a technique we already use to see if a field is initialized by >> application code. By default a field has to be a reference to a predefined >> object and the reference comparison (not equals) is used to check if the >> field is initialized by the user. >> >> Refer to IgniteConfiguration.failureDetectionTimeout and >> IgniteSpiAdapter.initializeFailureDetectionTimeout for more details. >> >> — >> Denis >> >>> On Aug 2, 2016, at 12:14 AM, Alexander Paschenko < >> alexander.a.pasche...@gmail.com> wrote: >>> >>> Dmitriy, >>> >>> Good point, however, currently there's no way to distinguish hash code >>> of zero which is a valid case from missing hash code. We probably >>> should enhance binary builder for it to handle this case. >>> >>> - Alex >>> >>> 2016-08-02 9:47 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: >>>> On Mon, Aug 1, 2016 at 11:38 PM, Vladimir Ozerov <voze...@gridgain.com> >>>> wrote: >>>> >>>>> Andrey, >>>>> >>>>> The question is when to print this warning. I doubt we can print a >> warning >>>>> when calling *BinaryObjectBuilder.build() *method, because an object >>>>> without a hash code is normal situation. >>>>> >>>>> >>>> I would not only print warning, but throw exception, if an object >> without a >>>> hashCode ends up on a put or read operation in cache. >>>> >>>> >>>>> On Tue, Aug 2, 2016 at 9:00 AM, Andrey Gura <ag...@gridgain.com> >> wrote: >>>>> >>>>>> I think we also should print some warning in case when hashCode() >> wasn't >>>>>> called on BinaryObject explicitly. >>>>>> >>>>>> On Tue, Aug 2, 2016 at 2:20 AM, Dmitriy Setrakyan < >> dsetrak...@apache.org >>>>>> >>>>>> wrote: >>>>>> >>>>>>> On Mon, Aug 1, 2016 at 10:01 AM, Alexey Goncharuk < >>>>>>> alexey.goncha...@gmail.com> wrote: >>>>>>> >>>>>>>> Dmitriy, >>>>>>>> >>>>>>>> The question is how do you calculate the value of the hashCode? Do >>>>> you >>>>>>> want >>>>>>>> it to be specified explicitly in INSERT statement? >>>>>>>> >>>>>>> >>>>>>> I think optionally we should allow to specify hashCode as part of the >>>>>>> INSERT statement. However, if it is not specified, we should >> calculate >>>>> it >>>>>>> automatically based in the key fields defined in the schema/type. >>>>> Agree? >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 2016-08-01 19:47 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org >>>>>> : >>>>>>>> >>>>>>>>> Alex, >>>>>>>>> >>>>>>>>> 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: >>>>>>>>> >>>>>>>>>> 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 (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 >>>>>>>>>> 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 >>>>>> >>>>> >> >>
