[
https://issues.apache.org/jira/browse/HBASE-8521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13659469#comment-13659469
]
Jean-Marc Spaggiari commented on HBASE-8521:
--------------------------------------------
So. First try attached.
Passed all the tests successfuly. (3 tests failed because of compilation issues
not related to this patch. Servlets, etc.)
{code}
hbase(main):001:0> create 'test', {NAME => 'myfam', VERSIONS => 100000, TTL =>
1000000000}
{code}
{code}
bin/hbase org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles familyDir1
test
{code}
{code}
hbase(main):001:0> scan 'test'
ROW COLUMN+CELL
aaaa column=myfam:myqual,
timestamp=1368157470713, value=oldVal
1 row(s) in 0.4190 seconds
{code}
{code}
bin/hbase org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles familyDir2
test
{code}
{code}
hbase(main):001:0> scan 'test'
ROW COLUMN+CELL
aaaa column=myfam:myqual,
timestamp=1368157470713, value=newVal
1 row(s) in 0.4330 seconds
{code}
So as said above, there is come incompatibility between he version.
One thing that I can change is to not pass the parameter if it's false so new
clients can still call old servers.
Open to comments.
> Cells cannot be overwritten with bulk loaded HFiles
> ---------------------------------------------------
>
> Key: HBASE-8521
> URL: https://issues.apache.org/jira/browse/HBASE-8521
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.92.1
> Reporter: Jonathan Natkins
> Attachments: HBASE-8521.diff, HBASE-8521-v0-0.94.patch,
> hfileDirs.tar.gz
>
>
> Let's say you have a pre-built HFile that contains a cell:
> ('rowkey1', 'family1', 'qual1', 1234L, 'value1')
> We bulk load this first HFile. Now, let's create a second HFile that contains
> a cell that overwrites the first:
> ('rowkey1', 'family1', 'qual1', 1234L, 'value2')
> That gets bulk loaded into the table, but the value that HBase bubbles up is
> still 'value1'.
> It seems that there's no way to overwrite a cell for a particular timestamp
> without an explicit put operation. This seems to be the case even after minor
> and major compactions happen.
> My guess is that this is pretty closely related to the sequence number work
> being done on the compaction algorithm via HBASE-7842, but I'm not sure if
> one of would fix the other.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
