How about we add a property - auto-generate hashCode() in binary configuration. If set, then we auto-generate the hashCode() every time a binary object is built.
Thoughts? On Fri, Aug 5, 2016 at 5:29 AM, Alexander Paschenko < alexander.a.pasche...@gmail.com> wrote: > 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 > >> >>>>>> > >> >>>>> > >> >> > >> >> > >> > >> >
