Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CA+0=VoUep+kf21vb5APbmRxzQj1+DCwwA1jsP-yOZf5E4M2fDQ@mail.gmail.com>
References: <CAGt6o8mcQwhqt1RsbRWJpXO5Xe5r1oMa=EXNHnqso=OMOh5cSQ@mail.gmail.com>
 <CA+eZwrH5L6SWWV_wim3thq0VYQm45WD_8QxMUrd=F1Un+m7tpg@mail.gmail.com>
 <CA+0=VoVeGmJW7h4jp360u5GS7qQ0oyMsh6YTOC2eTo_RyuCfiA@mail.gmail.com>
 <CA+eZwrFv6X12hMgwpAZqbZT8AvrCoG8m7pbhLh_JMephWKnvZw@mail.gmail.com>
 <CAK2_iMPO1+A457SxREabUb7COpXjbp1fhNAKM_jsQEQz4_cOSw@mail.gmail.com> <CA+0=VoUep+kf21vb5APbmRxzQj1+DCwwA1jsP-yOZf5E4M2fDQ@mail.gmail.com>
From: Sergi Vladykin <sergi.vladykin@gmail.com>
Date: Mon, 10 Apr 2017 18:33:19 +0300
Message-ID: <CA+eZwrFujBdb6BLw5s6LnJy-BmMxmfsXQXPUS+sTKCeO=Rb6fw@mail.gmail.com>
Subject: Re: Sorting fields of Binarilyzable objects on write
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a114dad1a4b6604054cd1b4cb
archived-at: Mon, 10 Apr 2017 15:34:06 -0000

--001a114dad1a4b6604054cd1b4cb
Content-Type: text/plain; charset=UTF-8

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 <dsetrakyan@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 <ptupitsyn@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.vladykin@gmail.com>
> > wrote:
> >
> > > What is correct or incorrect ordering for DML?
> > >
> > > Sergi
> > >
> > > 2017-04-10 18:14 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@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.vladykin@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 <vozerov@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
> > > > > >
> > > > >
> > > >
> > >
> >
>

--001a114dad1a4b6604054cd1b4cb--