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