[jira] [Commented] (LENS-1471) JoinCandidate's children should not share same instance of a storage candidate
[
https://issues.apache.org/jira/browse/LENS-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16153476#comment-16153476
]
Hudson commented on LENS-1471:
--
SUCCESS: Integrated in Jenkins build Lens-Commit #1439 (See
[https://builds.apache.org/job/Lens-Commit/1439/])
LENS-1471: JoinCandidate's children should not share same storage
(rajatgupta59: rev caf7a2c0b045ce409d254c1ff26ffd79d01fee52)
* (edit)
lens-cube/src/main/java/org/apache/lens/cube/parse/CandidateCoveringSetsResolver.java
* (edit)
lens-cube/src/main/java/org/apache/lens/cube/parse/StorageCandidate.java
* (edit) lens-cube/src/main/java/org/apache/lens/cube/parse/UnionCandidate.java
> JoinCandidate's children should not share same instance of a storage
> candidate
> ---
>
> Key: LENS-1471
> URL: https://issues.apache.org/jira/browse/LENS-1471
> Project: Apache Lens
> Issue Type: Bug
> Components: cube
>Reporter: Rajat Khandelwal
>Assignee: Rajat Khandelwal
> Fix For: 2.8
>
> Attachments: LENS-1471.01.patch, LENS-1471.02.patch,
> LENS-1471.03.patch
>
>
> The issue is in Join candidates of the kind {{Join\[Union\[a,b\];
> Union\[a,c\]\]}}. If the instance of {{a}} is shared in different trees of a
> JoinCandidate, the rewritten query will be wrong. JoinCandidate's children
> set exclusive measure phrase indices, and that is done via {{retain}} method
> of list. So let's say union1 is answering {{\[0,1\]}} measures and union2 is
> answering {{\[2,3\]}} measures, and since
> {{\[0,1,2,3\].retain(\[0,1\]).retain(\[2,3\]) == \[\]}}, it ends up answering
> no measures at all
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LENS-1471) JoinCandidate's children should not share same instance of a storage candidate
[
https://issues.apache.org/jira/browse/LENS-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16153425#comment-16153425
]
Rajat Khandelwal commented on LENS-1471:
Committed myself.
> JoinCandidate's children should not share same instance of a storage
> candidate
> ---
>
> Key: LENS-1471
> URL: https://issues.apache.org/jira/browse/LENS-1471
> Project: Apache Lens
> Issue Type: Bug
> Components: cube
>Reporter: Rajat Khandelwal
>Assignee: Rajat Khandelwal
> Fix For: 2.8
>
> Attachments: LENS-1471.01.patch, LENS-1471.02.patch,
> LENS-1471.03.patch
>
>
> The issue is in Join candidates of the kind {{Join\[Union\[a,b\];
> Union\[a,c\]\]}}. If the instance of {{a}} is shared in different trees of a
> JoinCandidate, the rewritten query will be wrong. JoinCandidate's children
> set exclusive measure phrase indices, and that is done via {{retain}} method
> of list. So let's say union1 is answering {{\[0,1\]}} measures and union2 is
> answering {{\[2,3\]}} measures, and since
> {{\[0,1,2,3\].retain(\[0,1\]).retain(\[2,3\]) == \[\]}}, it ends up answering
> no measures at all
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LENS-1471) JoinCandidate's children should not share same instance of a storage candidate
[
https://issues.apache.org/jira/browse/LENS-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16152621#comment-16152621
]
Hadoop QA commented on LENS-1471:
-
Applied patch:
[LENS-1471.03.patch|https://issues.apache.org/jira/secure/attachment/12885259/LENS-1471.03.patch]
and ran command: mvn clean install -fae. Result: Success. Build Job:
https://builds.apache.org/job/PreCommit-Lens-Build/1430/
> JoinCandidate's children should not share same instance of a storage
> candidate
> ---
>
> Key: LENS-1471
> URL: https://issues.apache.org/jira/browse/LENS-1471
> Project: Apache Lens
> Issue Type: Bug
> Components: cube
>Reporter: Rajat Khandelwal
>Assignee: Rajat Khandelwal
> Attachments: LENS-1471.01.patch, LENS-1471.02.patch,
> LENS-1471.03.patch
>
>
> The issue is in Join candidates of the kind {{Join\[Union\[a,b\];
> Union\[a,c\]\]}}. If the instance of {{a}} is shared in different trees of a
> JoinCandidate, the rewritten query will be wrong. JoinCandidate's children
> set exclusive measure phrase indices, and that is done via {{retain}} method
> of list. So let's say union1 is answering {{\[0,1\]}} measures and union2 is
> answering {{\[2,3\]}} measures, and since
> {{\[0,1,2,3\].retain(\[0,1\]).retain(\[2,3\]) == \[\]}}, it ends up answering
> no measures at all
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LENS-1471) JoinCandidate's children should not share same instance of a storage candidate
[
https://issues.apache.org/jira/browse/LENS-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16152579#comment-16152579
]
Rajat Khandelwal commented on LENS-1471:
Taking patch from reviewboard and attaching
> JoinCandidate's children should not share same instance of a storage
> candidate
> ---
>
> Key: LENS-1471
> URL: https://issues.apache.org/jira/browse/LENS-1471
> Project: Apache Lens
> Issue Type: Bug
> Components: cube
>Reporter: Rajat Khandelwal
>Assignee: Rajat Khandelwal
> Attachments: LENS-1471.01.patch, LENS-1471.02.patch,
> LENS-1471.03.patch
>
>
> The issue is in Join candidates of the kind {{Join\[Union\[a,b\];
> Union\[a,c\]\]}}. If the instance of {{a}} is shared in different trees of a
> JoinCandidate, the rewritten query will be wrong. JoinCandidate's children
> set exclusive measure phrase indices, and that is done via {{retain}} method
> of list. So let's say union1 is answering {{\[0,1\]}} measures and union2 is
> answering {{\[2,3\]}} measures, and since
> {{\[0,1,2,3\].retain(\[0,1\]).retain(\[2,3\]) == \[\]}}, it ends up answering
> no measures at all
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LENS-1471) JoinCandidate's children should not share same instance of a storage candidate
[
https://issues.apache.org/jira/browse/LENS-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16152497#comment-16152497
]
Hadoop QA commented on LENS-1471:
-
Applied patch:
[LENS-1471.02.patch|https://issues.apache.org/jira/secure/attachment/12885243/LENS-1471.02.patch]
and ran command: mvn clean install -fae. Result: Failure. Build Job:
https://builds.apache.org/job/PreCommit-Lens-Build/1429/
> JoinCandidate's children should not share same instance of a storage
> candidate
> ---
>
> Key: LENS-1471
> URL: https://issues.apache.org/jira/browse/LENS-1471
> Project: Apache Lens
> Issue Type: Bug
> Components: cube
>Reporter: Rajat Khandelwal
>Assignee: Rajat Khandelwal
> Attachments: LENS-1471.01.patch, LENS-1471.02.patch
>
>
> The issue is in Join candidates of the kind {{Join\[Union\[a,b\];
> Union\[a,c\]\]}}. If the instance of {{a}} is shared in different trees of a
> JoinCandidate, the rewritten query will be wrong. JoinCandidate's children
> set exclusive measure phrase indices, and that is done via {{retain}} method
> of list. So let's say union1 is answering {{\[0,1\]}} measures and union2 is
> answering {{\[2,3\]}} measures, and since
> {{\[0,1,2,3\].retain(\[0,1\]).retain(\[2,3\]) == \[\]}}, it ends up answering
> no measures at all
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LENS-1471) JoinCandidate's children should not share same instance of a storage candidate
[
https://issues.apache.org/jira/browse/LENS-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16152490#comment-16152490
]
Rajat Khandelwal commented on LENS-1471:
Taking patch from reviewboard and attaching
> JoinCandidate's children should not share same instance of a storage
> candidate
> ---
>
> Key: LENS-1471
> URL: https://issues.apache.org/jira/browse/LENS-1471
> Project: Apache Lens
> Issue Type: Bug
> Components: cube
>Reporter: Rajat Khandelwal
>Assignee: Rajat Khandelwal
> Attachments: LENS-1471.01.patch, LENS-1471.02.patch
>
>
> The issue is in Join candidates of the kind {{Join\[Union\[a,b\];
> Union\[a,c\]\]}}. If the instance of {{a}} is shared in different trees of a
> JoinCandidate, the rewritten query will be wrong. JoinCandidate's children
> set exclusive measure phrase indices, and that is done via {{retain}} method
> of list. So let's say union1 is answering {{\[0,1\]}} measures and union2 is
> answering {{\[2,3\]}} measures, and since
> {{\[0,1,2,3\].retain(\[0,1\]).retain(\[2,3\]) == \[\]}}, it ends up answering
> no measures at all
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
