Current design is documented here:
https://issues.apache.org/jira/browse/IGNITE-4011, it incorps both
equals and hashCode.
- Alex
2016-10-03 15:24 GMT+03:00 Dmitriy Setrakyan :
> On Mon, Oct 3, 2016 at 5:03 AM, Alexey Goncharuk > wrote:
>
>> Dima,
>>
>> Why do you think somebody will need to over
On Mon, Oct 3, 2016 at 5:03 AM, Alexey Goncharuk wrote:
> Dima,
>
> Why do you think somebody will need to override equals? Currently we do not
> have such an ability and AFAIK we did not have a single question regarding
> this. Other products, such as Hazelcast, rely solely on binary
> represent
Dima,
Why do you think somebody will need to override equals? Currently we do not
have such an ability and AFAIK we did not have a single question regarding
this. Other products, such as Hazelcast, rely solely on binary
representation of a key. If this is never used, why do we need to increase
the
Alex,
I can't post in the ticket, because my Jira login stopped working, so I
will post here.
I only have 1 question - do we purposely not support custom equals
implementation? Seems we could simply add 2 methods to the
BinaryObjectHashCodeResolver: isUseEquals() and computeEquals(). Having
said
I've posted proposed example of hash code resolver interface and XML
configuration for classless key on issue page
https://issues.apache.org/jira/browse/IGNITE-2294.
2016-09-29 20:16 GMT+03:00 Dmitriy Setrakyan :
> On Thu, Sep 29, 2016 at 9:57 AM, Denis Magda wrote:
>
>> Alex,
>>
>> A minor note
On Thu, Sep 29, 2016 at 9:57 AM, Denis Magda wrote:
> Alex,
>
> A minor note regarding this
>
> > On Sep 29, 2016, at 8:39 AM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
> >
> > A set of fields participating in hashCode and equals is impossible to
> > change without cluster restart.
Alex,
A minor note regarding this
> On Sep 29, 2016, at 8:39 AM, Alexey Goncharuk
> wrote:
>
> A set of fields participating in hashCode and equals is impossible to
> change without cluster restart.
It’s unlikely that someone will change a key or at least it should be a rare or
accidental
On Thu, Sep 29, 2016 at 9:19 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> I want to step back a little bit. Why do we need to choose fields for
> hashCode at all? If all fields participate in equals, all of them should
> participate in hashCode as well. We already serialize a user k
Dmitry,
Just list them in XML config, in the section about indexed types. Will
do proposal for that on issue page later today.
Regarding validation of the field list - currently there's no (and
hardly can be) protection against miscalculation of hash codes passed
to the BinaryObjectBuilder. It's
I want to step back a little bit. Why do we need to choose fields for
hashCode at all? If all fields participate in equals, all of them should
participate in hashCode as well. We already serialize a user key in order
to get a value from cache, so we can use a hashCode based on binary object
represe
In the assumption that we do not have 'non-equals' fields, binary array
comparison generally should be faster, because even if we did a
field-by-field comparison, we would read the same amount of data anyway,
but also would need to do some byte jiggling for type conversion.
2016-09-29 19:07 GMT+0
Alexander,
How do you plan to annotate fields that participate in the hashcode
calculation? Can you add all the changes you plan to make to the
configuration in the ticket and post the link here?
Also, we must make sure that hashcode fields do not change. I believe you
should have validation in t
Thanks everyone!
Denis, yes, that's what I meant, now we're on the same page :)
However, I'm worried about the same things Alexey is, that is, I'm not
sure how we can handle presence of key fields that don't participate
in 'equals' evaluation. Hence I'm all up for keeping mechanism of
comparison f
Alexey, in your opinion, what will be faster, the binary array comparison
or field-by-field comparison?
On Thu, Sep 29, 2016 at 8:39 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> Folks, let me point out a few obvious (or not) things
>
> A set of fields participating in hashCode and
Folks, let me point out a few obvious (or not) things
A set of fields participating in hashCode and equals is impossible to
change without cluster restart. Imagine a new client adding a field F to
key structure (A, B) so that new key is (A, B, F). In this case key (1, 2,
0) will be treated as a di
Guys,
We need to look at 3 cases:
a) key is just one field
b) key is multiple fields
c) key is one or multiple fields, with possibility of an alternate affinity
key
For (a) and (b), whenever a type is defined in XML, and further in DML, a
user will specify which fields are part of the key. In th
Let me show the picture I have in my mind:
Primary key is a must for all INSERT and MERGE operations. If it’s not set then
an INSERT/MERGE fails.
If a primary key is a boxed/unboxed primitive (int, Integer, String, Date,
etc.) then the key value is used for hashCode calculation. At the same time
Also MERGE.
2016-09-29 2:10 GMT+03:00 Denis Magda :
> You need a hash code only for INSERT operation, right?
>
> —
> Denis
>
>> On Sep 28, 2016, at 3:47 PM, Alexander Paschenko
>> wrote:
>>
>> But what if the user works from some kind of console and just types
>> the queries as text in full and
You need a hash code only for INSERT operation, right?
—
Denis
> On Sep 28, 2016, at 3:47 PM, Alexander Paschenko
> wrote:
>
> But what if the user works from some kind of console and just types
> the queries as text in full and does not bind params via JDBC or
> something alike? What if there
But what if the user works from some kind of console and just types
the queries as text in full and does not bind params via JDBC or
something alike? What if there's no binary object? I don't see why we
should keep the user from usual cache gets in this case. I really like
the idea of supplying the
Hmm, this is a good question.
If a user doesn’t provide a _key when an INSERT is executed for me it means
that he is not going to use the key later for cache.get/put, DELETE, UPDATE and
other possible operation simply because he doesn’t know how to reconstruct the
key back in his code. If he wa
Denis,
That's not what I was asking about.
Currently DML implementation allows for dymanic instantiation of keys,
in other words, user does not have to provide value for object-typed
_key column - instead, he may supply just field values based on which
_key will be dynamically instantiated/binary
Alexander,
As I guess if we have a key without a class then it will be constructed using a
BinaryBuilder instance and it’s user responsibility to set the has code at the
end with BinaryBuilder.hasCode method. Sure, all this cases must be
well-documented in both Java Doc API and Apache Ignite do
Dmitry, Denis,
OK, but I think it's necessary to address also the cases when there's
no actual class for the key, and its fields are simply declared in
XML. In this case, there are no fields to be marked transient. What do
we do then? List transient fields in XML separately?
- Alex
2016-09-28 4:
Agree with Denis.
- by default, all non-transient key fields should participate in the
hashcode generation
- when working on DDL, then the primary key fields should participate in
the hashcode
- we should add a resolver to override the default behavior (please
propose the interfa
Hi Alexander,
Vladimir’s proposal sounds reasonable to me. However we must keep in mind one
important thing. Binary objects were designed to address the following
disadvantages a regular serializer, like optimized marshaller, has:
necessity to deserialize an object on a server side every time it
Hello Igniters,
As DML support is near, it's critical that we agree on how we generate
hash codes for new keys in presence of binary marshaller. Actually,
this discussion isn't new - please see its beginning here:
http://apache-ignite-developers.2346864.n4.nabble.com/All-BinaryObjects-created-by-
27 matches
Mail list logo
