ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: All BinaryObjects created by BinaryObjectBuilder stored at the same partition by default
Date Tue, 02 Aug 2016 07:46:00 GMT
I still fail to understand the use case then. Do we want to support insert
via SQL and get via regular cache API? If yes, then specifying hashCode in
INSERT statement is not optional, because otherwise the next cache.get()
for the inserted key will not work. So, we either enforce user to always
specify a hashCode in insert statement, or force him to use our "automatic"
algorithm of hashCode calculation in his key objects. Both ways look fishy
to me.

2016-08-02 2:20 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:

> On Mon, Aug 1, 2016 at 10:01 AM, Alexey Goncharuk <
> alexey.goncharuk@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 <dsetrakyan@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.paschenko@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.
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message