[
https://issues.apache.org/jira/browse/HBASE-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889687#action_12889687
]
stack commented on HBASE-2406:
------------------------------
>From Bruno article, issues mentioned are:
+ Gets lack "...the ability to retrieve the latest version less than or equal
to a given timestamp, thus giving the 'latest' state of the record at a certain
point in time."
+ Major compactions are not invisible to the user: "...create three cell
versions at t1, t2 and t3, with a maximum-versions setting of 2. So when
getting all versions, only the values at t2 and t3 will be returned. But if you
delete the version at t2 or t3, the one at t1 will appear again. Obviously,
once a major compaction has run, such behavior will not be the case anymore..."
+ hbase-1485, where if two cells with same coordinates, we do not return latest
added
+ A put after a tombstone was put in will be overshadowed by the tombstone if
timestamp is older than the tombstone, though it went in after the tombstone
was added (I made an issue for this, HBASE-2847).
> Define semantics of cell timestamps/versions
> --------------------------------------------
>
> Key: HBASE-2406
> URL: https://issues.apache.org/jira/browse/HBASE-2406
> Project: HBase
> Issue Type: Task
> Components: documentation
> Reporter: Todd Lipcon
> Priority: Critical
> Fix For: 0.90.0
>
>
> There is a lot of general confusion over the semantics of the cell timestamp.
> In particular, a couple questions that often come up:
> - If multiple writes to a cell have the same timestamp, are all versions
> maintained or just the last?
> - Is it OK to write cells in a non-increasing timestamp order?
> Let's discuss, figure out what semantics make sense, and then move towards
> (a) documentation, (b) unit tests that prove we have those semantics.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
