Hey guys, False alarm, sorry about that. Our column-names are byte-concatenations of short integers and we had been constructing the column names wrongly before attempting a delete. We fixed the problem and we've been able to delete the columns without issue.
On Fri, Nov 1, 2013 at 4:19 PM, Robert Coli <rc...@eventbrite.com> wrote: > On Fri, Nov 1, 2013 at 8:15 AM, Suruchi Deodhar < > suruchi.deod...@generalsentiment.com> wrote: > >> I provide the timestamp as the current time and >> consistency_level=ConsistencyLevel.ALL. >> >> My questions wrt this are: >> 1. Is there a log where I can check whether the remove command registered >> successfully with the Cassandra nodes? >> (In my case, the thrift call was successfully executed but my queries >> still show data in the deleted column. I don't see logs in the system.log. ) >> > > This sounds unexpected. Have you tried deleting the same column via > cassandra-cli or cqlsh (as applicable)? If so, does it work? > > >> 2. Given that consistency_level=ConsistencyLevel.ALL, how much time does >> cassandra take to commit the delete and cassandra client to get updated >> data? >> > > In my understanding, zero time. CL.ALL means all replicas have > acknowledged the write, and therefore the write should be available in the > memtables of all nodes. > > =Rob >
