[
https://issues.apache.org/jira/browse/CASSANDRA-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259064#comment-15259064
]
Chris Lohfink commented on CASSANDRA-11656:
-------------------------------------------
The current mode is {{tstamp}} is the timestamp of the tombstone
"localDeletionTime". While the {{deletion_time}} is the "markedForDeleteAt". We
could just call them that exactly as it would be less ambiguous. Them being
longs/ints are the underlying data not how the transformer chooses to represent
them. I kinda like idea of having a "human" readable format too though thats
actually a local or utc iso date string since as is they are hard to read.
> sstabledump has inconsistency in deletion_time printout
> -------------------------------------------------------
>
> Key: CASSANDRA-11656
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11656
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Reporter: Wei Deng
> Labels: Tools
>
> See the following output (note the deletion info under the second row):
> {noformat}
> [
> {
> "partition" : {
> "key" : [ "1" ],
> "position" : 0
> },
> "rows" : [
> {
> "type" : "row",
> "position" : 18,
> "clustering" : [ "c1" ],
> "liveness_info" : { "tstamp" : 1461646542601774 },
> "cells" : [
> { "name" : "val0_int", "deletion_time" : 1461647421, "tstamp" :
> 1461647421344759 },
> { "name" : "val1_set_of_int", "path" : [ "1" ], "deletion_time" :
> 1461647320, "tstamp" : 1461647320160261 },
> { "name" : "val1_set_of_int", "path" : [ "10" ], "value" : "",
> "tstamp" : 1461647295880444 },
> { "name" : "val1_set_of_int", "path" : [ "11" ], "value" : "",
> "tstamp" : 1461647295880444 },
> { "name" : "val1_set_of_int", "path" : [ "12" ], "value" : "",
> "tstamp" : 1461647295880444 }
> ]
> },
> {
> "type" : "row",
> "position" : 85,
> "clustering" : [ "c2" ],
> "deletion_info" : { "deletion_time" : 1461647588089843, "tstamp" :
> 1461647588 },
> "cells" : [ ]
> }
> ]
> }
> ]
> {noformat}
> To avoid confusion, we need to have consistency in printing out the
> DeletionTime object. By definition, markedForDeleteAt is in microseconds
> since epoch and marks the time when the "delete" mutation happens;
> localDeletionTime is in seconds since epoch and allows GC to collect the
> tombstone if the current epoch second is greater than localDeletionTime +
> gc_grace_seconds. I'm ok to use "tstamp" to represent markedForDeleteAt
> because markedForDeleteAt does represent this delete mutation's timestamp,
> but we need to be consistent everywhere.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
