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 documentation.
— Denis > On Sep 28, 2016, at 9:33 AM, Alexander Paschenko > <alexander.a.pasche...@gmail.com> wrote: > > 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 >>> >>>
