Hello Luís,

Regarding the timestamp: it is designed to be mainly used for indicating
the time when this record is generated (i.e. CREATE_TIME at the producer
side, it will set the timestamp), or when the record has been appended to
Kafka brokers (i.e. LOG_APPEND_TIME at the broker side, where producer
would not set it, and even they do it will be ignored). I'm not sure I
understand you statement that it is used to determine the "version" of the
record? Could you point me to the KIP regarding this field?

Regarding the byte arrays: I think byte arrays are indeed comparable,
right? We can compare them lexicographically, for example:


On Wed, Apr 11, 2018 at 2:09 AM, Luís Cabral <luis_cab...@yahoo.com.invalid>

> Hi all,
> On my own previous statement:
> bq. Not that I mind doing it directly (I intend to use a Java client), but
> please be aware that a String binary representation is based on the charset
> encoding, while the Long binary representation varies according to the
> language.
> I went back to double check this, and it seems that parsing the binary
> directly to long is already done (e.g.: the 'timestamp' header), so I guess
> this is OK and I was simply over-engineering it.The KIP is now adapted to
> use long directly.
> On Guozhang's statement:
>  bq. I'm also in favor of making the `timestamp` a preserved config value
> along with `offset`, for which we would not go into the headers to look for
> the matching key, but directly look into the timestamp field of the message.
> In reviewing the previous point I think I understood this a bit better, in
> that you mean using the already existing 'timestamp' field, which the
> client can customize, in order to determine the version of the record.Would
> you then be OK with the client hijacking this when/if they need to use
> incremental versioning instead? There are some KIP's opened regarding this
> field, and this field itself is already used for other things, so it
> already has some meanings attached to it. I personally prefer to avoid
> attaching multiple meanings to a single field, but if it allows for this
> feature to go through, then I am OK with it.Please let me know your
> thoughts here.
> Cheers!

-- Guozhang

Reply via email to