You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Gabriel Reid (JIRA)" <ji...@apache.org> on 2013/10/15 10:07:48 UTC

[jira] [Updated] (HBASE-9763) Scan javadoc doesn't fully capture semantics of start and stop row

     [ https://issues.apache.org/jira/browse/HBASE-9763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gabriel Reid updated HBASE-9763:
--------------------------------

    Attachment: HBASE-9763.patch

Trivial patch to remove the trailing null byte information, and be a bit more clear about the use of scan start and stop as matching the row prefix.

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