[
https://issues.apache.org/jira/browse/HBASE-10571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906325#comment-13906325
]
Lars Hofhansl commented on HBASE-10571:
---------------------------------------
bq. a very costly way to send your data to /dev/null
:)
To twist your mind, what should happen when you set TTL to a negative value
(looks like we'd allow this too)?
Now even future KVs would already be expired :)
Seriously, though, we should guard against nonsensical settings. Looking at
HColumnDescriptor, it's a bit of a mess. We check some of the parameters, but
not all, and on top of that only in a constructor that marked deprecated in
favor of using setters, which in turn do no validation.
> TTL of zero should be rejected
> ------------------------------
>
> Key: HBASE-10571
> URL: https://issues.apache.org/jira/browse/HBASE-10571
> Project: HBase
> Issue Type: Bug
> Components: Admin
> Affects Versions: 0.94.16, 0.96.1.1
> Reporter: Jeremy Carroll
>
> If a table schema has been modified to provide a default TTL, or a TTL on a
> column of 0, then HBase basically becomes a very costly way to send your data
> to /dev/null.
> I'm proposing that we reject outright any attempt to set a TTL on a default
> table schema, or column of a value of zero. I cannot think of a use case
> where individuals would want to delete their keys as soon as they are written
> to the memstore. In addition, this will protect against any bugs in code, or
> documentation errors which would result in irrecoverable data loss.
> Example:
> hbase(main):001:0> create 'test_table', { NAME => 'd', TTL => 0 }
> 0 row(s) in 1.7880 seconds
> hbase(main):003:0> put 'test_table', 'row1', 'd', '1'
> 0 row(s) in 0.1300 seconds
> hbase(main):004:0> scan 'test_table'
> ROW COLUMN+CELL
>
>
> 0 row(s) in 0.0320 seconds
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
