Atomic increment/add

[jakeri]

This is a new pull request for @KevinOrtman atomic increment feature (tsuna#2) that was made against 1.X code base and never added master.

Basically the same code, except minor changes for 2.0 code base and using add-keyword instead of inc. There was some discussion about this in above mentioned pull request.

Another thing done is that I have disabled scheduleForCompaction(...) within the increment. Does this mean that a row created by add will never be compacted?
I would guess that compaction and atomic increment for already compacted values is not good fit.

Would like to see a discussion if this could be incorporated into the project.

[manolama]

I'll dig into this in a little bit and it could go into 2.1. Compaction and increments can be tricky. The best way to go about it might be to use a new qualifier heading (same format as annotations) for increments so that they aren't compacted, OR on a re-compaction, columns with the increment header could be added to existing compacted values.

[jakeri]

Yes, I have noticed that. :-)
I tested my code change some more and noticed it. I'll see if I can come up with some ideas based on your thoughts.

[manolama]

Great! Annotations use the 0x01 prefix so we could assign increments 0x02. They're always 8 byte unsigned ints in HBase so we don't need the length and type encoding in a qualifier so the other 2 or 4 bytes can be the offset. Using the prefix, compactions should be skipped in the same way they are for annotations.

[KevinOrtman]

That is a wonderful idea!

On Thu, Feb 27, 2014 at 9:15 AM, Chris Larsen [email protected]:

Great! Annotations use the 0x01 prefix so we could assign increments 0x02.
They're always 8 byte unsigned ints in HBase so we don't need the length
and type encoding in a qualifier so the other 2 or 4 bytes can be the
offset. Using the prefix, compactions should be skipped in the same way
they are for annotations.

Reply to this email directly or view it on GitHubhttps://github.com//pull/265#issuecomment-36251821
.

[manolama]

Avoid re-arranging imports if possible. Just clutters PRs.

[farito]

Hi, what happend with this PR ? was merged?