Hi, Right now deletes work by inserting a special delete marker, aka "tombstone" complete with timestamp. The issue happens when you create a delete with a timestamp in the future, it masks deletes that have not happened yet. This is what I mean by "delete forward" - you are deleting data that hasn't been inserted yet! From those used to systems like MySQL, this is very confusing, hence this proposal.
-ryan On Sat, Jan 8, 2011 at 1:29 AM, Henning Blohm <[email protected]> wrote: > +1 from here as well > > Please let delete work as if it was just a special marker value of a > column (i.e. with a time stamp and all). > > On Fri, 2011-01-07 at 19:24 -0800, M. C. Srivas wrote: > >> +1 >> >> Just a clarification : by delete-forward, do you mean that a delete of a >> non-existent key causes a future insert of the key to get deleted? >> >> >> On Fri, Jan 7, 2011 at 4:23 PM, Ryan Rawson <[email protected]> wrote: >> >> > Hi all, >> > >> > We are thinking of getting rid of the "delete forward" misfeature in >> > HBase. The one way we'd implement it would permanently remove this >> > "feature", and prevent it from being put back in ever. >> > >> > What is a delete forward you ask? This is where you do a delete, but >> > because deletes are really just inserting 'tombstones', it applies to >> > future Puts. This can be immensely frustrating because puts appear to >> > do nothing. These rogue deletes get pruned out when the table is major >> > compacted, so it isn't forever. >> > >> > Because of the transient nature of these delete forwards, we suspect, >> > but do not know, if anyone is depending on this behaviour. If you use >> > this behaviour, please chime in so we can get a sense of what people >> > need! >> > >> > Thanks! >> > -ryan >> > >
