The way the delete tracker works (for the delete case) takes a delete at time t then the next put it encounters at time t-n it removes and then lifts the delete filter. I think this makes sense, especially since for time "t" a put sorts before a delete.
If a user wants to delete a value at time "j" then they should stamp the delete at j+1. If we want to allow deletes set to time "t" to affect puts at time t, we'll need to change the sorting of the type. Neither of these will affect gets since the deletes affect older files only will be maintained, furthermore the scanning minor compactor will ensure this invariant. On May 18, 2009 11:26 AM, "Jonathan Gray (JIRA)" <[email protected]> wrote: [ https://issues.apache.org/jira/browse/HBASE-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710436#action_12710436] Jonathan Gray commented on HBASE-1304: -------------------------------------- I think everyone is in agreement about the future. Any stamp given on anything (put or delete) that is > now, becomes now. As far as a Delete at LATEST, yes right now it needs to be an exact match. So, a Delete at LATEST will likely not do anything. Delete is for a single version. DeleteColumn is for all versions <= a specified stamp. So if you want to delete the latest version of something, you don't need to know it's stamp as long as you don't mind clearing all versions before it. Any time you want to delete _only_ a single version, you must know and specify the exact stamp. I think that is fair and understandable, to do otherwise I fear will sacrifice some of the good properties. Perhaps we can figure a way to do a single-version delete of the latest version of a column without affecting older ones. But it seems you'll have to either actually perform some kind of Get during the delete to figure the stamp, which there is not currently any of outside of touching Memcache, or all of our DeleteTracker'ing will need to change how it handles Deletes. Thoughts from others? > New client server implementation of how gets and puts are handled. > ---------------------------...
