Also, tombstone's are not "attached" anywhere. A tombstone is just a column with special value which says "I was deleted". And I am pretty sure they go into SSTables etc the exact same way regular columns do.
-----Original Message----- From: Jeremiah Jordan [mailto:jeremiah.jor...@morningstar.com] Sent: Tuesday, June 14, 2011 11:22 AM To: user@cassandra.apache.org Subject: RE: Docs: "Why do deleted keys show up during range scans?" I am pretty sure how Cassandra works will make sense to you if you think of it that way, that rows do not get deleted, columns get deleted. While you can delete a row, if I understand correctly, what happens is a tombstone is created which matches every column, so in effect it is deleting the columns, not the whole row. A row key will not be forgotten/deleted until there are no columns or tombstones which reference it. Until there are no references to that row key in any SSTables you can still get that key back from the API. -Jeremiah -----Original Message----- From: AJ [mailto:a...@dude.podzone.net] Sent: Monday, June 13, 2011 12:11 PM To: user@cassandra.apache.org Subject: Re: Docs: "Why do deleted keys show up during range scans?" On 6/13/2011 10:14 AM, Stephen Connolly wrote: > > store the query inverted. > > that way empty -> deleted > I don't know what that means... get the other columns? Can you elaborate? Is there docs for this or is this a hack/workaround? > the tombstones are stored for each column that had data IIRC... but at > this point my grok of C* is lacking I suspected this, but wasn't sure. It sounds like when a row is deleted, a tombstone is not "attached" to the row, but to each column??? So, if all columns are deleted then the row is considered deleted? Hmmm, that doesn't sound right, but that doesn't mean it isn't ! ;o)
