I even think that in DML we have to just calculate hashCode in order of QueryEntity regardless of order in Binarylizable.
Sergi 2017-04-10 18:29 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > Does anyone disagree about having users sort the fields themselves, as > Sergi and I suggested above? > > On Mon, Apr 10, 2017 at 8:21 AM, Pavel Tupitsyn <ptupit...@apache.org> > wrote: > > > Sergi, DML writes fields in alphabetic order and computes hash code > > accordingly. > > If user-defined Binarylizable impl uses different order, hash codes will > be > > inconsistent. > > > > On Mon, Apr 10, 2017 at 6:18 PM, Sergi Vladykin < > sergi.vlady...@gmail.com> > > wrote: > > > > > What is correct or incorrect ordering for DML? > > > > > > Sergi > > > > > > 2017-04-10 18:14 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > > > > > I would agree that it should be on a user to always sort the fields, > if > > > we > > > > make it a part of the contract. However, in this case, we should > always > > > > throw exception if user somehow provides fields in the wrong order. > > > > > > > > D. > > > > > > > > On Mon, Apr 10, 2017 at 8:07 AM, Sergi Vladykin < > > > sergi.vlady...@gmail.com> > > > > wrote: > > > > > > > > > Could you please elaborate why would we want to sort fields in > > > > > Binarilyzable > > > > > classes? > > > > > > > > > > If you are taking from stable binary representation perspective, > > then I > > > > > think it is a problem of user, but not ours. > > > > > > > > > > Sergi > > > > > > > > > > 2017-04-10 17:53 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > > > > > > > > > > > Zapalniki, > > > > > > > > > > > > Inspired by IGNITE-4669 (.NET: Sort binary object fields) [1]. > > > > > > > > > > > > Currently we sort binary object fields before when writing them > to > > > the > > > > > > output stream in case of standard (Serializable) objects and > > > > > > BinaryObjectBuilder. This makes sense as we have stable binary > > object > > > > > > representation irrespective of fields order, which is very > > important > > > > e.g. > > > > > > for DML. And it works fine from performance perspective as well: > > > > > > - For standard classes we sort fields only once during > > > initialization; > > > > > > - For builder we have to maintain the whole object graph in > memory > > > > before > > > > > > writing anyway as builder is mutable, so sorting doesn't impose > > > serious > > > > > > performance hit. > > > > > > > > > > > > But what to do with Binarilyzable classes? We can sort their > fields > > > as > > > > > > well, but it means that: > > > > > > 1) We will not be able to write them directly to stream. Instead, > > we > > > > will > > > > > > accumulate values in memory, and write only when the whole object > > > graph > > > > > is > > > > > > known. > > > > > > 2) Currently reads are mostly sequential from memory perspective. > > > With > > > > > this > > > > > > change reads will become random. > > > > > > > > > > > > So we will loose both read and write serialization performance. > How > > > do > > > > > you > > > > > > think - do we need this change or not? > > > > > > > > > > > > Vladimir. > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-4669 > > > > > > > > > > > > > > > > > > > > >
