Denis, Thank you very much for your proposed solution, I will reflect it in issue's comments and implement this check in code. Most likely this has to be an issue by itself.
However, it all does not answer the main question of this thread - how do we automatically supply hash codes for newly built binary objects? This is very important for convenient use of SQL inserts. Please, all, share your thoughts. - Alex 2016-08-03 3:23 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > On Tue, Aug 2, 2016 at 7:36 AM, Denis Magda <dma...@gridgain.com> wrote: > >> 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? >> > > It does to me. If there are no objections, then we should list this in the > ticket and implement the proposed suggestion of throwing exception if a > binary object without hashcode is used as a key. > > >> >> — >> 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 >> >>>>>> >> >>>>> >> >> >> >> >> >>
