[
https://issues.apache.org/jira/browse/CASSANDRA-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263383#comment-15263383
]
Chris Lohfink commented on CASSANDRA-11656:
-------------------------------------------
I kinda like idea of defaulting to human readable. A better experience for
first time people and adhoc browsing I think would be good. I can increase
precision of date string to include the same precision of the timestamp if that
helps?
{code}
{ "name" : "val1_set_of_int", "deletion_info" : { "marked_deleted" :
"2016-04-26T13:55:09.560266Z", "local_delete_time" : "2016-04-26T13:55:09Z" } },
{code}
(will upload patch in CASSANDRA-11655)
Ill defer the decision though on which is default.
> 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)