shrijeet/asynchbase — comment on commit 23194627f9fd2d24b61ba3c8e718df7c61327635
File:  line 0
By shrijeet:

Benoit, thank you for comments. I overlooked this part. I went through serialization code of `MultiPutRequest`. I feel if we include commit below https://github.com/shrijeet/asynchbase/commit/efdcbc760b9b98a2e5273894649ebcc523487b92 (NOTE: this commit is on top of my commit that makes sure we keep timestamp for `KeyValue` instance) , this block of code in `serialize` method should make sure we dont loose timestamp of individual KeyValues.

final KeyValue kv = edit.kv();
nbytes_per_family += kv.predictSerializedSize();
kv.serialize(buf, KeyValue.PUT);
prev = edit;

What will remain is what to do with this, the time stamp at row level

// Timestamp. We always set it to Long.MAX_VALUE, which means "unset".
// The RegionServer will set it for us, right before writing to the WAL
// (or to the Memstore if we're not using the WAL).
buf.writeLong(Long.MAX_VALUE);

What do you think Benoit?

On a side note, my understanding is not clear why HBase keeps a timestamp at row level, when it has it at KV level. In the `org.apache.hadoop.hbase.client.Put` the field `timestamp` is used if user does not specify a TS for each row individually using `add` method.
That way all KVs for that row share timestamp value.

I might have misunderstood code some where, dont mean any disrespect to your concern.