I agree, the use case I can see would be a view counter. In a single op you would retrieve the value and increment both on the returned value and the column value. Instead of a two step process where you would do a get, then send the incr call.
Perhaps another case would be a system where you want to have a finite set of say, beta keys. There you would use a get-decr. Though with EC you could possibly return more keys than intended, as some of the decr calls could be made on inconsistent values. Perhaps a quorum would be necessary as an option? (Typed on my phone, please excuse typos) -----Original Message----- Date: Wednesday, November 04, 2009 5:32:16 pm To: cassandra-user@incubator.apache.org From: "Jonathan Mischo" <jmis...@quagility.com> Subject: Re: Incr/Decr Counters in Cassandra incr/decr actually fit with EC, since they're just add n or sub n ops that can be replayed in any order...it's just less costly to do it as a get and incr or get and decr than as separate operations...the only difference between a get on the value followed by an incr is the overhead of the additional request, so it just seems to make a lot more sense to make it a single call. It's done in the SQL world a lot, and it's just good form, since a lot of times you're going to see an incr or decr tied to a get with a counter (but not always...sometimes you'll see just a get or an incr or decr...if you just have incr or decr return the new value, that works just as well, and the client can decide whether or not to discard the value). On Nov 4, 2009, at 4:09 PM, Bill de hOra wrote: > incr/decr for counters maybe doesn't fit with EC (as you might need > a global lock for some use cases ), but plus/minus are slightly > different as they're commutative and don't require a total
