[
https://issues.apache.org/jira/browse/HBASE-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889949#action_12889949
]
stack commented on HBASE-2406:
------------------------------
.bq ...by setting max to be the timestamp+1
What are you suggesting? That you do the Get with ts+1? Or you are suggesting
that you get more than one version and then the app figures out what to do?
Does that work? What if there is an entry at ts+1? App has to check for this?
On, re-surfacing Puts, you say "Seems like there's an argument on both sides of
this." I agree. Lets just decide and document what we decided (I suggest
current behavior is what we go with).
Regards not nailing-down behavior until we figure stuff like what to do in
minor compactions, I'd think that rather, that we should just say how we want
it to be and then implement toward this goal rather than let whatever the
current state of implementation shape our behavior.
> 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.
