You do realize that it is an internal feature and that the public API can change to not present access to it.
However, that wouldn’t be a good idea because you would want to be able to change it and in some cases review the versions of a cell. How else do you describe versioning which is unique to HBase and/or other specific databases, yet temporal modeling is not?
In fact if memory servers… going back to 2009-10 IIRC the ‘old API’ vs the ‘new API’ for Hadoop where the ‘new API’ had a subset of the exposed classes / methods than the old API? (It was an attempt to simplify the API… ) So again, APIs can change.
The point is that you should be modeling your data on time if it is time sensitive data. Using versioning bypasses this with bad consequences.
By all means keep abusing the cell’s versioning.
Just don’t complain about poor performance and your HBase tossing exceptions left and right. I mean I can’t stop you from mixing booze, coke and meth. All I can do is tell you that its not a good idea and not recommended.
If you want a good definition of why HBase has versioning… go ask StAck, Ted, Nick or one of the committers since they are more familiar with the internal workings of HBase than I. When you get a good answer, then have the online HBase book updated.
PS… if you want a really good example of why not to use versioning to store temporal data…
What happens if you’re storing 100 versions of a cell and you find out that you have a duplicate entry with the wrong timestamp and you want to delete that one version.
How do you do that? Going from memory, and I could very well be wrong, but the tombstone marker is on the cell, not the version, right?
If it is on the version, what happens to the versions of the cell that are older than the tombstone marker?
Sorry, its been a while since I’ve been intimate with HBase. Doing a bit of other things at the moment, and I’m already overtaxing my last remaining living brain cell. ;-)
On Apr 12, 2014, at 9:14 PM, Brian Jeltema <[EMAIL PROTECTED]> wrote: