You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Jonathan Gray (JIRA)" <ji...@apache.org> on 2010/09/08 19:25:34 UTC
[jira] Resolved: (HBASE-997) Count versions with same r/c/ts as one
instance with most recent addition the winner
[ https://issues.apache.org/jira/browse/HBASE-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Gray resolved HBASE-997.
---------------------------------
Hadoop Flags: [Incompatible change, Reviewed] (was: [Incompatible change])
Fix Version/s: 0.90.0
Resolution: Fixed
Fixed with commit of HBASE-1485.
> Count versions with same r/c/ts as one instance with most recent addition the winner
> ------------------------------------------------------------------------------------
>
> Key: HBASE-997
> URL: https://issues.apache.org/jira/browse/HBASE-997
> Project: HBase
> Issue Type: Improvement
> Reporter: stack
> Assignee: Pranav Khaitan
> Fix For: 0.90.0
>
>
> A few of us were chatting yesterday. If two edits go into hbase with same r/c/ts and they both go into the same memcache instance -- i.e. there has not been a flush between additions -- then the last insert will overwrite any added earlier (edits go into a Map). That seems fine to me (what others think?). But if a flush happens in between edits, hbase gives back different answers. Here's how.
> Each instance of a cell is treated as a 'version', even if same r/c/ts. If you ask for N > 1 versions, and if two cells of same r/c/ts, only there has been a flush between their additions, you'll get back two versions with same r/c/ts. If no flush between their upload, you'll get back one version only because the later overrode the former.
> This issue is about closing this hole. Suppress same r/c/ts when returning 'versions'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.