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 interface in Jira) - we should print out a warning, only once per type, the the hashcode has been automatically generated based on which fields and which formula
D. On Tue, Sep 27, 2016 at 5:42 PM, Denis Magda <dma...@gridgain.com> wrote: > 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’s needed. > necessity to hold an object in both serialized and deserialized forms on > the server node. > necessity to restart the whole cluster each time an object version is > changed (new field is added or an old one is removed). > If it will be needed to perform step 3 for a default implementation of the > binary resolver just because the resolver has to consider new fields or > ignore old ones then such an implementation sucks. Overall, the default > implementation should use the reflection coming over all the fields a key > has ignoring the ones that are marked with “transient” keyword. If a user > wants to control the default resolver's logic then he can label all the > fields that mustn’t be of a final has code value with “transient”. This has > to be well-documented for sure. > > Makes sense? > > — > Denis > > > On Sep 26, 2016, at 12:40 PM, Alexander Paschenko < > alexander.a.pasche...@gmail.com> wrote: > > > > 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 > >
