You don't "update" an old value, instead you insert the new value with a new timestamp and then readers see that value instead.
Multiple values at the same timestamp will always result in undeterminate return order. If the ts are the same, how do we know which one is newer? Id avoid inserting with "random timestamps", conceptually it doesn't make sense, since ts isn't just a 64 bit int but has specific semantic interpretation, you risk getting nonsensicial results. On Jun 16, 2009 12:49 PM, "Xinan Wu" <[email protected]> wrote: I am aware that inserting data into hbase with random timestamp order results indeterminate result. e.g. comments here https://issues.apache.org/jira/browse/HBASE-1249#action_12682369 I've personally experienced indeterminate results before when I insert in random timestamp order (i.e., multiple versions with same timestamp in the same cell, out-of-order timestamp when getting multiple versions). In other words, we don't want to go back in time in inserting cells. Deletion is ok. But is updating pretty much the same story as inserting? i.e., if I make sure the timestamp does exist in the cell, and then I _update_ it with that timestamp (and same value length), sometimes hbase still just inserts a new version without touching the old one, and of course timestamps of this cell becomes out of order. Even if I delete all versions in that cell and reinsert in the time order, the result is still out of order. I assume if I do a major compact between delete all and reinsert, it would be ok, but that's not a good solution. Is there any good way to update a version of a cell in the past? or that simply won't work? Thanks,
