[
https://issues.apache.org/jira/browse/CASSANDRA-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497841#comment-13497841
]
Sylvain Lebresne commented on CASSANDRA-4963:
---------------------------------------------
bq. because the user sees only one column
Maybe but that that colum still is composed of multiple values/records, and
those values can be set separately. And in fact we'll likely add later some
capacity to even query only subpart of the collection. A collection may be a
column, but it's clearly not (from an API standpoint) an opaque and atomic
value. So I would find it unintuitive if
{noformat}
UPDATE foo USING TTL 10 SET map['x'] = 'y' WHERE k = 1
{noformat}
was setting the ttl for all the pre-existing map records, but I suppose that's
somewhat a personal opinion/taste and I won't pretend to know what is more
intuitive for others.
But while I'm giving my somewhat personal opinion, I do feel uneasy about
assigning ttls at the level of something that is not atomic from the API point
of view (that being collection-level, cql3 row level or even internal row
level, which we've talked in the past). The fact that if you insert some value
(without putting a specific ttl) inside whatever "container" that is about to
expire, then it may either expire in one second or it may survives forever
depending on the exact timing of the expiration makes it imo hard to reason
about. That's definitely a personal feeling, but only having ttl at the level
of what is atomic for the API (as we do now) avoids that kind of consideration
and for that reason I do really think that it makes for a better, cleaner
semantic.
bq. you are destroying the integrity of the users data. It is exactly the same
as saying, when i tombstone a string column, i'm just going change the value to
"dead". Users can then see that and know what happened
You've lost me, sorry, I'm not sure I see what you mean by "destroying the
integrity of the users data" in the context of this ticket.
bq. may have a set column where i know the valid legal states are <empty> A,
AB, or ABC. But tombstoning could return a value of AC, which is not a valid
state
I don't understand. Are you suggesting that we shouldn't allow removing an
indiviual element from a set at all (in that case B) because that could break
some random assertion someone may want to have on its data? If AC is not
acceptable, then just never delete B alone (since this could lead to AC). And
the same stand for ttl, don't ever ttl B alone. I mean I don't think it makes
any sense to talk about cassandra breaking users data integrity since C* has no
way for the user to define its integrity constraint in the first place.
> 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
