[
https://issues.apache.org/jira/browse/CASSANDRA-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497080#comment-13497080
]
Sylvain Lebresne commented on CASSANDRA-4963:
---------------------------------------------
Let me first scratch some of my previous comment. I was a bit too quick and in
fact we could actually implement a collection level ttl without requiring a
read.
That being said, I still like the fact that per-collection-value ttl is more
flexible (I do think there is value in being able to individually set a ttl to
each elements). Also, while I can buy that:
{noformat}
UPDATE foo USING TTL 10 SET l = l + [1, 2] WHERE k = 1
{noformat}
updates the ttl of the existing elements of l based on the fact that l appears
on the right side of the equality, I do think that the same would be very
unintuitive for:
{noformat}
UPDATE foo USING TTL 10 SET map['x'] = 'y' WHERE k = 1
{noformat}
Indeed why would setting a new value with a ttl in the map set the whole map
ttl?
I will agree though that we have a problem with our current semantic in that I
believe
{noformat}
SELECT ttl(m) ...
{noformat}
is broken if m is a collection (and it would be more clear what to return if
the ttl was at the collection level). That being said, we have the same problem
with the write_time() function, and we can't just set the same timestamp to all
the collection elements, so I'd argue that it's a different problem and
whatever solution we pick for write_time() will work for ttl() too.
bq. FTR I think the "right" unit of ttl to expose is the (cql3) row.
I disagree. My argument at pretty much the same ones that for collection level
(loss of flexibility, unintuive syntax). Except that I feel more strongly
against it because we loose even more flexibility and I have personally use the
case of storing some (but not all) of the profile informations for users with
at ttl (there was legal reasons).
> A cql collection 'column' doesn't own it's ttl
> ----------------------------------------------
>
> Key: CASSANDRA-4963
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4963
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.0 beta 2
> Reporter: Dave Brosius
> Priority: Minor
>
> if you add a collection column with a ttl, then later update the collection
> by adding a new element, the 'under the covers' column representing the added
> value has no ttl. It seems like ttl tombstoning should only be allowed to
> remove the collection in entirety, or not touch it, but not be allowed to
> modify it by removing parts.
> example
> cqlsh> create keyspace collections with replication =
> {'class':'SimpleStrategy', 'replication_factor':1};
> cqlsh> use collections;
> cqlsh:collections> create table collections (key int primary key, aset
> set<text>);
> cqlsh:collections> insert into collections (key, aset) values (1, {'fee',
> 'fi'}) using ttl 10000;
> cqlsh:collections> update collections set aset = aset + {'fo', 'fum'} where
> key = 1;
> cqlsh:collections> exit
> cassandra-cli
> [default@unknown] use collections
> [default@collections] get collections[1];
> => (column=, value=, timestamp=1352874321877000)
> => (column=aset:666565, value=, timestamp=1352874314717000, ttl=10000)
> => (column=aset:6669, value=, timestamp=1352874314717000, ttl=10000)
> => (column=aset:666f, value=, timestamp=1352874321877000)
> => (column=aset:66756d, value=, timestamp=1352874321877000)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
