[
https://issues.apache.org/jira/browse/HBASE-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl resolved HBASE-1774.
----------------------------------
Resolution: Won't Fix
The Javadoc should suffice
> 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
