cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4963) A cql collection 'column' doesn't own it's ttl
Date Thu, 15 Nov 2012 08:34:12 GMT

    [ 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

Mime
View raw message