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