Hi, Thanks for the response – would this be a viable feature request? We’re moving from using raw HBase to Phoenix and would like to use this ‘countdown’ feature to allow for different rows in the same table to have different retention times. Instead of having to index a user created TTL column and create a script to manually garbage collect the stale rows, we could continue to leverage HBase’s TTL mechanism to automatically exclude the rows and physically delete them on the next major compaction.
>From the documentation, Phoenix supports TTL on secondary indexes as long as >they are created with the same value as the base table, which would be perfect! Thanks, -Alex. From: Yuhao Bi [mailto:[email protected]] Sent: September 23, 2015 00:31 To: user Subject: Re: Setting a TTL in an upsert Hi, As I know, we can only set a ttl in create table stage corresponding to HBase table ttl. CREATE TABLE IF NOT EXISTS my_schema.my_table ( org_id CHAR(15), entity_id CHAR(15), payload binary(1000), CONSTRAINT pk PRIMARY KEY (org_id, entity_id) ) TTL=86400 See http://phoenix.apache.org/language/index.html#create_table <http://phoenix.apache.org/language/index.html> for more grammar detail. Thanks, 2015-09-23 15:11 GMT+08:00 Alex Loffler <[email protected]>: Hi, Is it possible to define the TTL of a row (or even each cell in the row) during an upsert e.g: upsert into test values(1,2,3) TTL=1442988643355; Assuming the table has a TTL this would allow per-row retention policies (with automatic garbage-collection by HBase) by e.g. setting the upsert TTL to a time in the future. For example if the TTL on the table is set to 60 (seconds), a row with a desired retention policy of 1 year could be upserted with a TTL=now() + 1 year. Thanks in advance, -Alex.
smime.p7s
Description: S/MIME cryptographic signature
