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] > > >
