errata: "so c(123) means a counter column of ttl=1," ====> "so c(123) means a counter column of ttl=123,"
On Sun, May 29, 2011 at 12:24 AM, Yang <teddyyyy...@gmail.com> wrote: > sorry to beat on the dead horse. > > I looked at the link referred from #2103 : > https://issues.apache.org/jira/browse/CASSANDRA-2101 > I agree with the reasoning in #2101 that the ultimate issue is that delete > and counter adds are not commutative. since by definition we can't achieve > predictable behavior with deletes + counter, can we redefine the behavior > of counter deletes, so that we can always guarantee the declared behavior? > --- specifically: > > > *we define that once a counter column is deleted, you can never add to it > again.* attempts to add to a dead counter throws an exception ---- all > future adds are just ignored. i.e. a counter column has only one life, > until all tombstones are purged from system, after which it is possible for > the counter to have a new incarnation. basically instead of solving the > problem raised in #2103, we declare openly that it's unsolvable (which is > true), and make the code reflect this fact. > > > > I think this behavior would satisfy most use cases of counters. so instead > of relying on the advice to developers: "do not do updates for a period > after deletes, otherwise it probably wont' work", we enforce this into the > code. > > > the same logic can be carried over into expiring column, since they are > essentially automatically inserted deletes. that way #2103 could be "solved" > > > I'm attaching an example below, you can refer to them if needed. > > Thanks a lot > Yang > > > example: > for simplicity we assume there is only one column family , one column, so > we omit column name and cf name in our notation, assume all counterColumns > have a delta value of 1, we only mark their ttl now. so c(123) means a > counter column of ttl=1, adding a delta of 1. d(456) means a tombstone with > ttl=456. > > then we can have the following operations > > operation result after operation > ---------------------------------------------------------------------- > c(1) count=1 > d(2) count = null ( counter not present ) > > c(3) count = null ( add on dead counter ignored) > --------------------------------------------------- > > > if the 2 adds arrive out of order , we would still guarantee eventual > consistency: > > operation result after operation > > -------------------------------------------------------------------------------- > c(1) count=1 > c(3) count=2 (we have 2 adds, each with > delta=1) > d(2) count=null (deleted) > -------------------------------------------------------------- > at the end of both scenarios, the result is guaranteed to be null; > note that in the second scenario, line 2 shows a snapshot where we have a > state with count=2, which scenario 1 never sees this. this is fine, since > even regular columns can have this situation (just consider if the counter > columns were inserts/overwrites instead ) > > > > On Fri, May 27, 2011 at 5:57 PM, Jonathan Ellis <jbel...@gmail.com> wrote: > > No. See comments to https://issues.apache.org/jira/browse/CASSANDRA-2103 > > > > On Fri, May 27, 2011 at 7:29 PM, Yang <teddyyyy...@gmail.com> wrote: > >> is this combination feature available , or on track ? > >> > >> thanks > >> Yang > >> > > > > > > > > -- > > Jonathan Ellis > > Project Chair, Apache Cassandra > > co-founder of DataStax, the source for professional Cassandra support > > http://www.datastax.com > > > >
