Hi Radim, This is the current behaviour you will see if you are inserting a row tombstone in a counter CF, as the row tombstone does not remove the old counter value from the memtable. When you increment the counter after deleting the row, the counter now has a timestamp later than the row tombstone, and the new value is resolved with the old value which is still in the memtable.
The behaviour described on the wiki and by others in this thread is what you will see if inserting a column tombstone for your counter. Sam -- Sam Overton Acunu | http://www.acunu.com | @acunu On 21 September 2011 16:49, Radim Kolar <h...@sendmail.cz> wrote: > Dne 21.9.2011 14:44, David Boxenhorn napsal(a): > >> The reason why counters work is that addition is commutative, but deletes >> are not commutative >> > This is not my case. if you look at my 2 posts. > 1st post seems to be CLI bug because same operation from program works > fine. > In 2nd post i already see that counter is deleted and it can not be > caused by message ordering because it is single node cluster > > in 1.0 Beta 1. case reported in my 1st post is fixed, but 2nd problem still > exists; > > on single node cluster: -> increment -> delete -> increment with 1 sec > delays should work. How it can be fine to return stale value by counter > design? >
