> More likely data in that row was created with a
> higher-res timestamp than the delete was issued at.
Indeed - the problem was nanos v millis with a bit of clock skew thrown
in :)
Bill
Jonathan Ellis wrote:
remove to a full row doesn't touch comparewith at all. I think that's
a red herring. More likely data in that row was created with a
higher-res timestamp than the delete was issued at.
On Thu, May 27, 2010 at 7:27 AM, Bill de hOra <b...@dehora.net> wrote:
Saw some behaviour today on Cassandra 0.6.1 -
After running a remove command on a row in a CF whose CompareWith was
BytesType the row was still there, and still there after bouncing the
server. This was the case for hector/cli. When I changed the CompareWith to
UTF8Type, new rows added could be removed (old rows wouldn't delete).
Was wondering if anyone else had seen this.
Bill
