Vova, can you give an example of when writing out of order would be the
only option?
On Thu, Apr 13, 2017 at 4:20 AM, Vladimir Ozerov
wrote:
> Folks,
>
> If you restrict writes in certain order and conditions, Binarylizable
> interfaces turns into an unusable bullshit :-) Remember that not all b
Folks,
If you restrict writes in certain order and conditions, Binarylizable
interfaces turns into an unusable bullshit :-) Remember that not all binary
objects participate in DML, and even if so, not all binary objects are
cache keys. I think we should simply print a warning to log, informing use
That is cool, completely forgot about it :)
2017-04-13 14:07 GMT+03:00 Pavel Tupitsyn :
> Alexey, we can read fields in any order in non-raw mode.
> Dmitriy's suggestion would work.
>
> On Thu, Apr 13, 2017 at 1:56 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > Dmitriy,
> >
> >
Alexey, we can read fields in any order in non-raw mode.
Dmitriy's suggestion would work.
On Thu, Apr 13, 2017 at 1:56 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> Dmitriy,
>
> How would then reader determine which field to read (a and b could the of
> different size)? c in this ca
Dmitriy,
How would then reader determine which field to read (a and b could the of
different size)? c in this case must be written first.
2017-04-13 0:29 GMT+03:00 Dmitriy Setrakyan :
> Vladimir,
>
> Would this be valid?
>
> *void writeBinary(BinaryWriter w) {*
>
> *if (c)*
> *w.writ
Vladimir,
Would this be valid?
*void writeBinary(BinaryWriter w) {*
*if (c)*
*w.writeInt("A", a)*
*else*
*w.writeInt("B", b)*
*w.writeBoolean("C", c);*
*}*
D.
On Wed, Apr 12, 2017 at 1:07 AM, Vladimir Ozerov
wrote:
> Consider the following code:
>
> void writeBin
Vladimir,
I think we have to disallow conditional writes here, because DML should
write all the fields, no?
Sergi
2017-04-12 11:07 GMT+03:00 Vladimir Ozerov :
> Consider the following code:
>
> void writeBinary(BinaryWriter w) {
> w.writeBoolean("C", c);
>
> if (c)
> w.writeInt(
Consider the following code:
void writeBinary(BinaryWriter w) {
w.writeBoolean("C", c);
if (c)
w.writeInt("A", a)
else
w.writeInt("B", b)
}
How are we going to force user to follow the contract in this case?
On Wed, Apr 12, 2017 at 9:16 AM, Dmitriy Setrakyan
wrote:
I think it is OK for users to do their own sorting, but we should
definitely validate the correct order and throw an exception if it is not.
D.
On Tue, Apr 11, 2017 at 11:02 PM, Pavel Tupitsyn
wrote:
> QueryEntity order is not only harder for the users, it will be nightmare to
> implement.
> Wh
QueryEntity order is not only harder for the users, it will be nightmare to
implement.
What if there is no QueryEntity defined? What if the same class is used in
multiple QueryEntity?
I don't think serialization code has to be tied to QueryEntity in any way,
this violates separation of concerns.
S
On Tue, Apr 11, 2017 at 1:28 PM, Sergi Vladykin
wrote:
> I'm just trying to understand the current state of things and risks. May be
> we need to do some adjustments here before 2.0 to be on the safe side.
>
> Actually looks like this not really important, we just have to clearly
> document that
I'm just trying to understand the current state of things and risks. May be
we need to do some adjustments here before 2.0 to be on the safe side.
Actually looks like this not really important, we just have to clearly
document that DML builds keys this way and require from user to do the same
to b
Sergi, why do you not like the alphabetical order? Seems like it would be a
much easier to understand requirement from the user standpoint. Do you see
some issues here?
On Mon, Apr 10, 2017 at 10:43 AM, Sergi Vladykin
wrote:
> I'm sorry, looks like I do not really well understand this stuff, but
I'm sorry, looks like I do not really well understand this stuff, but it is
still not clear to me why wouldn't we just take the order of key fields
given in QueryEntity and use it for both cases irrespectively to the order
of fields in regular Class or in Binarylizable?
I mean lets say we have a C
Guys,
The problem is that order of fields serialization is unknown for regular
objects, where "regular" stands for non-Binarilyzable class. Reflection
returns fields in unpredictable order. For this reason you cannot match
fields order between class and QueryEntity. This is why we introduced
sorti
Why "regular" are different here?
Sergi
2017-04-10 18:59 GMT+03:00 Pavel Tupitsyn :
> QueryEntity sorting is not an option for "regular" classes with reflective
> serialization.
> We have to use alphabetical.
> Also, same class can participate in multiple query entities.
>
> 10 апр. 2017 г. 18:5
QueryEntity sorting is not an option for "regular" classes with reflective
serialization.
We have to use alphabetical.
Also, same class can participate in multiple query entities.
10 апр. 2017 г. 18:52 пользователь "Dmitriy Setrakyan" <
dsetrak...@apache.org> написал:
On Mon, Apr 10, 2017 at 8:28
On Mon, Apr 10, 2017 at 8:28 AM, Sergi Vladykin
wrote:
> The decision to use alphabetic order looks strange here. Using order
> provided in QueryEntity and require from user to have the same order
> in Binarylizable
> looks more reasonable.
>
I think this would be much harder to verify. Alphabet
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 :
> Does anyone disagree about having users sort the fields themselves, as
> Sergi and I suggested above?
>
> On Mon, Apr 1
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
wrote:
> Sergi, DML writes fields in alphabetic order and computes hash code
> accordingly.
> If user-defined Binarylizable impl uses different orde
The decision to use alphabetic order looks strange here. Using order
provided in QueryEntity and require from user to have the same order
in Binarylizable
looks more reasonable.
Sergi
2017-04-10 18:21 GMT+03:00 Pavel Tupitsyn :
> Sergi, DML writes fields in alphabetic order and computes hash cod
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
wrote:
> What is correct or incorrect ordering for DML?
>
> Sergi
>
> 2017-04
What is correct or incorrect ordering for DML?
Sergi
2017-04-10 18:14 GMT+03:00 Dmitriy Setrakyan :
> 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 fi
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
wrote:
> Could you please ela
I agree with performance concerns.
BinarYLizable (why don't we rename it to Binarizable already, btw?) used to
be
the fastest approach to serialization (and it makes sense that manual
approach is the best).
With sorting it won't be so anymore.
On the other hand, incorrect ordering will break DML i
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 :
> Zapalniki,
>
> Inspired by IGNITE-4669
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 irresp
27 matches
Mail list logo
