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