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