The iterator that processes delete markers is setup by the system and
you can not get below it. Delete markers are only dropped on a full
major compaction. So you could force a major compaction of the table,
or a range of the table. Or you can insert with a timestamp greater
than the delete marker.
On Thu, Jan 17, 2013 at 8:59 AM, Roshan Punnoose <[EMAIL PROTECTED]> wrote:
> We had noticed some interesting behavior in our Accumulo instance. When we delete a row and add that exact same row (with the same timestamp) after the delete, the row still does not exist. It makes sense because the delete really just adds a delete row that tells Accumulo to ignore any row that is equal to it. Is there a way to bypass this? Where I could set up my own iterator to decide if a row should be deleted or not? (not sure how I would decide yet, but just seeing if it is possible to bypass the delete logic as is)
> I tried to set up an Iterator in priority=1 to see if I could see a delete row, but it did not seem to make it to my iterator.
> Any ideas?
> Roshan Punnoose
> [EMAIL PROTECTED]