[
https://issues.apache.org/jira/browse/HBASE-17584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15924368#comment-15924368
]
stack commented on HBASE-17584:
-------------------------------
Patch looks great. +1
On compatibility, adding a new method to our base result scanner Interface
(ResultScanner @InterfaceAudience.Public, @InterfaceStability.Stable), reading
over our guarantees, I see what you cite, "New APIs introduced in a patch
version will only be added in a source compatible way [1]: i.e. code that
implements public APIs will continue to compile.", but then on the end: "A
minor upgrade requires no application/client code modification. Ideally it
would be a drop-in replacement but client code, coprocessors, filters, etc
might have to be recompiled if new jars are used." Adding an API to an
Interface when there is no default implementation would require
application/client code modification, right?, so that means it is not allowed?
Thats how I interpret it. Correct me if I have it wrong.
> Expose ScanMetrics with ResultScanner rather than Scan
> ------------------------------------------------------
>
> Key: HBASE-17584
> URL: https://issues.apache.org/jira/browse/HBASE-17584
> Project: HBase
> Issue Type: Sub-task
> Components: Client, mapreduce, scan
> Affects Versions: 2.0.0, 1.4.0
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17584.patch, HBASE-17584-v1.patch
>
>
> I think this have been discussed many times... It is a bad practice to
> directly modify the Scan object passed in when calling getScanner. The reason
> that we can not use a copy is we need to use the Scan object to expose scan
> metrics. So we need to find another way to expose the metrics.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
