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: https://github.com/apache/kafka/blob/196bcfca0c56420793f85514d1602bde564b0651/clients/src/main/java/org/apache/kafka/common/utils/Bytes.java#L144 Guozhang On Wed, Apr 11, 2018 at 2:09 AM, Luís Cabral <luis_cab...@yahoo.com.invalid> wrote: > > 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
