hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-1774) HTable$ClientScanner modifies its input parameters
Date Wed, 21 Dec 2011 23:17:30 GMT

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

Lars Hofhansl commented on HBASE-1774:

Unfortunately making a copy is no longer possible in trunk because of ScanMetrics, which are
collected on the Scan object itself. If we make a copy the copy will have its metrics populated.

Could keep a reference to copied copied, but then the application may have to walk a chain
of these references. I think we should just document this at this point. I'm in this code
right now anyway (HBASE-4439)... I'll add JavaDoc for this.
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message