[
https://issues.apache.org/jira/browse/CASSANDRA-6394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Varilly updated CASSANDRA-6394:
---
Description:
When selecting and inserting/updating columns, one can get/set the TIMESTAMP /
WRITETIME and TTL. However, this is not enough information to recreate the
column's expiration time (clock sync and network latency between the client and
server get in the way). This makes updating columns with a set TTL fragile:
there is no way to make the new value of a column *expire* at the same time as
the old value.
Ideally, you'd be able to say something like:
SELECT x, y EXPIRATIONTIME( y ) FROM my_cf
and
UPDATE my_cf USING EXPIRATIONTIME sameAsFromSelect SET y = newy WHERE x = oldx.
The use case I'm facing is that I write an entire row with a given TTL, and
might later want to update a few of its columns. Currently, that makes the
updated columns live longer than the non-updated columns. Of course, you can
come up with a good approximation for the appropriate TTL in the update to make
the updated columns expire at *around* the same time, but not at *exactly* the
same time. Since Cassandra stores an expiration time internally, making the
expiration *exactly* simultaneous should be possible, but CQL3 does not expose
this ability.
was:
When selecting and inserting/updating columns, one can get/set the TIMESTAMP /
WRITETIME and TTL. However, this is not enough information to recreate the
column's expiration time (clock sync and network latency between the client and
server get in the way). This makes updating columns with a set TTL fragile:
there is no way to make the new value of a column *expire* at the same time as
the old value.
Ideally, you'd be able to say something like:
SELECT x, y EXPIRATIONTIME(y) FROM my_cf
and
UPDATE my_cf USING EXPIRATIONTIME sameAsFromSelect SET y = newy WHERE x = oldx.
The use case I'm facing is that I write an entire row with a given TTL, and
might later want to update a few of its columns. Currently, that makes the
updated columns live longer than the non-updated columns. Of course, you can
come up with a good approximation for the appropriate TTL in the update to make
the updated columns expire at *around* the same time, but not at *exactly* the
same time. Since Cassandra stores an expiration time internally, making the
expiration *exactly* simultaneous should be possible, but CQL3 does not expose
this ability.
> Accessing and setting expiration time of a column (instead of TTL)
> --
>
> Key: CASSANDRA-6394
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6394
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
>Reporter: Patrick Varilly
>Priority: Minor
> Labels: cql3, features, timestamp, ttl
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> When selecting and inserting/updating columns, one can get/set the TIMESTAMP
> / WRITETIME and TTL. However, this is not enough information to recreate the
> column's expiration time (clock sync and network latency between the client
> and server get in the way). This makes updating columns with a set TTL
> fragile: there is no way to make the new value of a column *expire* at the
> same time as the old value.
> Ideally, you'd be able to say something like:
> SELECT x, y EXPIRATIONTIME( y ) FROM my_cf
> and
> UPDATE my_cf USING EXPIRATIONTIME sameAsFromSelect SET y = newy WHERE x =
> oldx.
> The use case I'm facing is that I write an entire row with a given TTL, and
> might later want to update a few of its columns. Currently, that makes the
> updated columns live longer than the non-updated columns. Of course, you can
> come up with a good approximation for the appropriate TTL in the update to
> make the updated columns expire at *around* the same time, but not at
> *exactly* the same time. Since Cassandra stores an expiration time
> internally, making the expiration *exactly* simultaneous should be possible,
> but CQL3 does not expose this ability.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
