cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Lohfink (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-11656) sstabledump has inconsistency in deletion_time printout
Date Tue, 26 Apr 2016 22:22:12 GMT

    [ 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)

Mime
View raw message