hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-1774) HTable$ClientScanner modifies its input parameters
Date Mon, 08 Apr 2013 05:13:16 GMT

    [ https://issues.apache.org/jira/browse/HBASE-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13625147#comment-13625147
] 

Anoop Sam John commented on HBASE-1774:
---------------------------------------

So now we can this note in the javadoc for HTableInterface#getScanner(Scan scan)
{code}
* Note that the passed {@link Scan}'s start row and caching properties
* maybe changed.
{code}
[~lhofhansl] we can close this issue as WontFix?
                
> HTable$ClientScanner modifies its input parameters
> --------------------------------------------------
>
>                 Key: HBASE-1774
>                 URL: https://issues.apache.org/jira/browse/HBASE-1774
>             Project: HBase
>          Issue Type: Bug
>          Components: Client
>    Affects Versions: 0.20.0
>            Reporter: Jim Kellerman
>            Assignee: Jim Kellerman
>            Priority: Critical
>
> HTable$ClientScanner modifies the Scan that is passed to it on construction.
> I would consider this to be bad programming practice because if I wanted to use the same
Scan object to scan multiple tables, I would not expect one table scan to effect the other,
but it does.
> If input parameters are going to be modified either now or later it should be called
out *loudly* in the javadoc. The only way I found this behavior was by creating an application
that did scan multiple tables using the same Scan object and having 'wierd stuff' happen.
> In my opinion, if you want to modify a field in an input parameter, you should:
> - make a copy of the original object
> - optionally return a reference to the copy.
> There is no javadoc about this behavior. The only thing I found was a comment in HTable$ClientScanner:
> {code}
>     // HEADSUP: The scan internal start row can change as we move through table.
> {code}
> Is there a use case that requires this behavior? If so, I would recommend that ResultScanner
 (and the classes that implement it) provide an accessor to the mutable copy of the input
Scan and leave the input argument alone.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message