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:15 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > 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 >> >>
