[
https://issues.apache.org/jira/browse/CALCITE-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798113#comment-16798113
]
Ruben Quesada Lopez edited comment on CALCITE-2937 at 3/21/19 1:54 PM:
-----------------------------------------------------------------------
[~julianhyde], I agree that we can generally see an Enumerable as basically a
supplier of an Enumerator, but it has more than that, for example all the
implementations of the ExtendedEnumerable methods.
In the use case that originated this ticket (CALCITE-2909 "Optimize Enumerable
SemiJoin with lazy computation of innerLookup"), I initially tried to create a
version of LazyEnumerable based on AbstractEnumerable (overriding the
{{Enumerable<T> getThis()}} method to return the lazy enumerable via supplier).
However, that approach broke the unit tests. The reason is that
AbstractEnumerable extends DefaultEnumerable, which implements all the
ExtendedEnumerable methods using EnumerableDefaults implementations, and that
was not correct in my scenario (EnumerableSemiJoin innerLookup.contais(...)).
Concretely, that LazyEnumerable based on AbstractEnumerable would use
EnumerableDefaults#contains, whereas the "real" Enumerable used
CollectionEnumerable#contains implementation.
For this reason, I think that a generic "WrapperEnumerable" (or
"ForwardingEnumerable") approach could be a good, reusable solution for that
problem.
was (Author: rubenql):
[~julianhyde], I agree that we can generally see an Enumerable as basically a
supplier of an Enumerator, but it has more than that, for example all the
implementations of the ExtendedEnumerable methods.
In the use case that originated this ticket (CALCITE-2909 "Optimize Enumerable
SemiJoin with lazy computation of innerLookup"), I initially tried to create a
version of LazyEnumerable based on AbstractEnumerable (overriding the
{{Enumerable<T> getThis()}} method to return the lazy enumerable via supplier).
However, that approach broke the unit tests. The reason is that
AbstractEnumerable extends DefaultEnumerable, which implements all the methods
using EnumerableDefaults implementations, and that was not be correct in my
scenario (EnumerableSemiJoin innerLookup.contais(...)). Concretely, that
LazyEnumerable based on AbstractEnumerable would use
EnumerableDefaults#contains, whereas the "real" Enumerable used
CollectionEnumerable#contains implementation.
For this reason, I think that a generic "WrapperEnumerable" (or
"ForwardingEnumerable") approach could be a good, reusable solution for that
problem.
> Linq4j: implement LazyEnumerable
> --------------------------------
>
> Key: CALCITE-2937
> URL: https://issues.apache.org/jira/browse/CALCITE-2937
> Project: Calcite
> Issue Type: New Feature
> Reporter: Ruben Quesada Lopez
> Assignee: Ruben Quesada Lopez
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Implement a LazyEnumerable: an Enumerable whose computation (via a Supplier)
> will be postponed until it is actually required.
> An example of use case could be CALCITE-2909, where a semiJoin implementation
> can be optimized by delaying the computation of the innerLookup until the
> moment when we are sure that it will be really needed, i.e. when the first
> outer enumerator item is processed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
