[
https://issues.apache.org/jira/browse/PHOENIX-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maryann Xue resolved PHOENIX-3279.
----------------------------------
Resolution: Fixed
Committed. Thank you, [~jamestaylor], for the review!
> QueryPlan.iterator(ParallelScanGrouper scanGrouper) should pass null
> ('unknown') as scan parameter when calling this.iterator(ParallelScanGrouper
> scanGrouper, Scan scan)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-3279
> URL: https://issues.apache.org/jira/browse/PHOENIX-3279
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.8.0
> Reporter: Maryann Xue
> Assignee: Maryann Xue
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3279.patch
>
>
> This issue was introduced by PHOENIX-2628, and it caused a regression in
> CalciteIT after calcite branch was synced with master branch.
>
> In most implementations of QueryPlan.iterator(ParallelScanGrouper
> scanGrouper), the QueryPlan calls this.iterator(ParallelScanGrouper
> scanGrouper, Scan scan) with a Scan object it gets from its inner QueryPlan.
> This logic is actually wrong when a ScanPlan (or AggregatePlan) is nested in
> two or more DelegateQueryPlans. For example,
> TupleProjectionPlan(ClientScanPlan(ScanPlan), the TupleProjectionPlan will
> pass the ClientScanPlan.getContext().getScan() to
> ClientScanPlan.iterator(ParallelScanGrouper scanGrouper, Scan scan), and in
> turn to ScanPlan.iterator(ParallelScanGrouper scanGrouper, Scan scan), which
> will shadow the original Scan object in the ScanPlan.
>
> It would be better to just pass "null" in indicate "unknown" in this case.
> The QueryPlan which does care about the Scan object, which is mostly
> BaseQueryPlan, will have to handle this "null" value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
