[
https://issues.apache.org/jira/browse/HBASE-9763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797015#comment-13797015
]
Gabriel Reid commented on HBASE-9763:
-------------------------------------
Thanks for taking a look. The difference between your test and my example is
that my example is based on a row key prefix, and your test is based on full
matching. Like the discussion and previous bug in the docs in HBASE-9035,
there's a lot of potential for confusion when appending null bytes to get
different semantics.
I think this is a potentially confusing topic for users not matter what.
Another option instead of removing the null-byte appending advice from the
javadoc might be to qualify it with more information around the semantics of
what the start row and end row of a scan really are. Or maybe I'm just worrying
too much about it and it's not really that big of an issue. :-)
> Scan javadoc doesn't fully capture semantics of start and stop row
> ------------------------------------------------------------------
>
> Key: HBASE-9763
> URL: https://issues.apache.org/jira/browse/HBASE-9763
> Project: HBase
> Issue Type: Bug
> Components: documentation
> Reporter: Gabriel Reid
> Priority: Minor
> Attachments: HBASE-9763.patch
>
>
> The current javadoc for Scan#setStartRow and Scan#setStopRow methods don't
> accurately capture the semantics of the use of row prefix values. Both
> methods describe the use of a trailing null byte to change the
> inclusive/exclusive the respective semantics of setStartRow and setStopRow.
> The use of a trailing null byte for start row exclusion only works in the
> case that exact full matching is done on row keys. The use of a trailing null
> byte for stop row inclusion has even more limitations (see HBASE-9035).
> The basic example is having the following rows:
> {code}
> AAB
> ABB
> BBC
> BCC
> {code}
> Setting the start row to A and the stop row to B will include AAB and AB.
> Setting the start row to A\x0 and the stop row to B\x0 will result in the
> same two rows coming out of the scan, instead of having an effect on the
> inclusion/exclusion semantics.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
