Guozhang, is this reply ok with you?
If you insist on the byte[] comparison directly, then I would need some
suggestions on how to represent a "version" with it, and then the KIP could be
changed to that.
On Tuesday, April 17, 2018, 2:44:16 PM GMT+2, Luís Cabral
<luis_cab...@yahoo.com> wrote:
Oops, missed that email...
bq. It is because when we compare the bytes we do not treat them as longs
atall, so we just compare them based on bytes; I admit that if users's
headertypes have some semantic meanings (e.g. it is encoded from a long) they
weare forcing them to choose the encoder that obeys key lexicographicordering;
but I felt it is more general than enforcing any fields that maybe used for log
cleaner to be defined as a special type.
Yes, you can compare bytes between each other (its what that code does). You
can then assume (or infer) that the encoding used allows for lexicographic
ordering, which I hope you do not do a lot of. This is (logically) the same as
converting to String and then comparing the strings, except that it allows for
abstracting from the String encoding (again, either with assumptions or with
inferred knowledge).
This is purely academic, however, as the versioning is based on a long, which
is not compatible with this approach. So, is this comment a fact-check stating
that it is possible to compare byte[] overall, or is it about trying to use it
in this KIP?
Cheers
PS (because I'm stubborn): It is still not comparable, this comparison is all
based on assumptions about the content of the byte array, but I hope we can
leave this stuff to Stack Overflow instead of debating it here :)
