[
https://issues.apache.org/jira/browse/CASSANDRA-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030667#comment-13030667
]
Sylvain Lebresne commented on CASSANDRA-2620:
---------------------------------------------
There's no point in going into too much details, but the TTL was use internally
in a first version of the patch without realizing it shouldn't be. So yes the
TTL is not used internally but we forgot to reconsider removing it at the time.
But the thing is, we return it to the client. This was initially chosen over a
delta TTL so as to preserve the "mathematical" equality that for a column c, c
== get(insert(c)) (and I'm talking equality of the thrift structure, and hence
this wouldn't be true in general because the delta TTL return would be
different from the initial one). But probably nobody care this property
actually stands, not arguing.
Anyway, I do agree that retrospectively we should have gone without persisting
the TTL. However, changing what we return to the client would make the upgrade
of those that rely on it (I know at least one production system that does) both
painful and error prone. So I think I'm -1 on this.
> Don't persist TTL for expiring columns
> --------------------------------------
>
> Key: CASSANDRA-2620
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2620
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Stu Hood
> Priority: Minor
> Fix For: 1.0
>
>
> We persist both the TTL (5 seconds from now) and the localExpirationTime (the
> local time at +5 seconds) for expiring columns, but the TTL is never used
> again, except when we return expiring columns to clients.
> Rather than storing the TTL to return to clients, we could calculate a delta
> TTL value by subtracting the current time from the localExpirationTime, and
> save 4 bytes on disk.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
