Wei Deng created CASSANDRA-11656:
------------------------------------
Summary: 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
See the following output:
{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)
