hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gabriel Reid (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9763) Scan javadoc doesn't fully capture semantics of start and stop row
Date Wed, 16 Oct 2013 17:19:42 GMT

    [ 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)

Mime
View raw message