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-BinaryObjectBuilder-stored-at-the-same-partition-by-default-td8042.html

Still, I'm creating this new thread to make getting to the final
solution as simple and fast as possible.

I remind everyone that the approach that has got the least critics was
the one proposed by Vladimir Ozerov:

<quote>
I think we can do the following:
1) Add "has hash code" flag as Denis suggested.
2) If object without a hash code is put to cache, throw an exception.
3) Add *BinaryEqualsHashCodeResolver *interface.
4) Add default implementation which will auto-generate hash code. *Print a
warning when auto-generation occurs*, so that user is aware that he is
likely to have problems with normal GETs/PUTs.
5) Add another implementation which will use encoded string to calculate a
hash code. E.g. *new BinaryEqualsHashCodeResolver("{a} * 31 + {b}")*.
Originally proposed by Yakov some time ago.
</quote>

After that, Sergi suggested that instead of a "formula" we keep just a
list of the "fields" that participate in hash code evaluation, and
with that list, we simply calculate hash code just like IDE does -
with all its bit shifts and additions.

I'm planning on settling down with this combined Vlad-Sergi approach.
Any objections?

And an extra question I have: Vlad, you suggest that we both throw an
exception on cache code absence and that we might generate it as the
last resort. Do I understand you correctly that you suggest generating
random code only in context of SQL, but throw exception for keys
without codes on ordinary put?

And yes, built-in hash codes for JDK types are supported as well as
items 1-2 from Vlad's list (there's already fixed issue of IGNITE-3633
for the flag and its presence check).

- Alex

Reply via email to