Re: [2/2] calcite git commit: [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of ES adapter (Andrei Sereda)

[Julian Hyde]

Same failure for me on JDK 8/macOS. The most likely other variable is maven: I 
have 3.5.2 on macOS, 3.5.3 on ubuntu.

I’m mystified why no one else is seeing javadoc failures on macOS.

Julian


> On Jun 22, 2018, at 4:35 PM, Julian Hyde  wrote:
> 
> On JDK 8/ubuntu, “mvn clean -DskipTests site” gives the following failure:
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on project 
> calcite-mongodb: Error generating maven-javadoc-plugin:3.0.1:test-javadoc 
> report: 
> [ERROR] Exit code: 1 - 
> /home/jhyde/open1/calcite.4/mongodb/src/test/java/org/apache/calcite/adapter/mongodb/MongoAdapterTest.java:22:
>  error: cannot find symbol
> [ERROR] import org.apache.calcite.test.CalciteAssert;
> [ERROR]   ^
> [ERROR]   symbol:   class CalciteAssert
> [ERROR]   location: package org.apache.calcite.test
> [ERROR] 
> /home/jhyde/open1/calcite.4/mongodb/src/test/java/org/apache/calcite/adapter/mongodb/MongoAdapterTest.java:137:
>  error: package CalciteAssert does not exist
> [ERROR]   private CalciteAssert.AssertThat assertModel(String model) {
> [ERROR]^
> [ERROR] 
> /home/jhyde/open1/calcite.4/mongodb/src/test/java/org/apache/calcite/adapter/mongodb/MongoAdapterTest.java:145:
>  error: package CalciteAssert does not exist
> [ERROR]   private CalciteAssert.AssertThat assertModel(URL url) {
> [ERROR]^
> [ERROR] 
> /home/jhyde/open1/calcite.4/mongodb/src/test/java/org/apache/calcite/test/MongoAssertions.java:43:
>  error: reference not found
> [ERROR]   /** Similar to {@link CalciteAssert#checkResultUnordered}, but 
> filters strings
> [ERROR] ^
> 
> 
> 
>> On Jun 22, 2018, at 3:46 PM, Andrei Sereda  wrote:
>> 
>> Hmm. Both master and c12cb4b0de work for me. Perhaps the issue is JDK 8 vs
>> 9 ?
>> 
>> # JDK8 (oracle) /  macOS
>> $ mvn clean -DskipTests site
>> 
>> On Fri, Jun 22, 2018 at 5:56 PM Julian Hyde  wrote:
>> 
>>> I just tried it again. The following fails for me (jdk9, ubuntu):
>>> 
>>> $ git checkout c12cb4b0de
>>> $ mvn clean -DskipTests site
>>> 
>>> Constructing Javadoc information...
>>> 1 error
>>> [INFO]
>>> 
>>> [INFO] Reactor Summary:
>>> [INFO]
>>> [INFO] Calcite 1.17.0-SNAPSHOT  FAILURE [02:29
>>> min]
>>> [INFO] Calcite Linq4j . SKIPPED
>>> [INFO] Calcite Core ... SKIPPED
>>> [INFO] Calcite Cassandra .. SKIPPED
>>> [INFO] Calcite Druid .. SKIPPED
>>> [INFO] Calcite Elasticsearch .. SKIPPED
>>> [INFO] Calcite Elasticsearch5 . SKIPPED
>>> [INFO] Calcite Examples ... SKIPPED
>>> [INFO] Calcite Example CSV  SKIPPED
>>> [INFO] Calcite Example Function ... SKIPPED
>>> [INFO] Calcite File ... SKIPPED
>>> [INFO] Calcite Geode .. SKIPPED
>>> [INFO] Calcite MongoDB  SKIPPED
>>> [INFO] Calcite Pig  SKIPPED
>>> [INFO] Calcite Piglet . SKIPPED
>>> [INFO] Calcite Plus ... SKIPPED
>>> [INFO] Calcite Server . SKIPPED
>>> [INFO] Calcite Spark .. SKIPPED
>>> [INFO] Calcite Splunk . SKIPPED
>>> [INFO] Calcite Ubenchmark 1.17.0-SNAPSHOT . SKIPPED
>>> [INFO]
>>> 
>>> [INFO] BUILD FAILURE
>>> [INFO]
>>> 
>>> [INFO] Total time: 02:29 min
>>> [INFO] Finished at: 2018-06-22T14:53:13-07:00
>>> [INFO]
>>> 
>>> [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
>>> project calcite: Error generating maven-javadoc-plugin:3.0.1:test-aggregate
>>> report:
>>> [ERROR] Exit code: 1 -
>>> /home/jhyde/open1/calcite.4/elasticsearch2/src/test/java/org/apache/calcite/adapter/elasticsearch2/EmbeddedElasticNode.java:29:
>>> error: package org.elasticsearch.node.internal does not exist
>>> [ERROR] import org.elasticsearch.node.internal.InternalSettingsPreparer;
>>> [ERROR]   ^
>>> [ERROR]
>>> [ERROR] Command line was: /usr/lib/jvm/jdk9/bin/javadoc @options @packages
>>> @argfile
>>> [ERROR]
>>> [ERROR] Refer to the generated Javadoc files in
>>> '/home/jhyde/open1/calcite.4/target/site/testapidocs' dir.
>>> [ERROR] -> [Help 1]
>>> [ERROR]
>>> [ERROR] To see the 

Re: [2/2] calcite git commit: [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of ES adapter (Andrei Sereda)

[Julian Hyde]

On JDK 8/ubuntu, “mvn clean -DskipTests site” gives the following failure:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on project 
calcite-mongodb: Error generating maven-javadoc-plugin:3.0.1:test-javadoc 
report: 
[ERROR] Exit code: 1 - 
/home/jhyde/open1/calcite.4/mongodb/src/test/java/org/apache/calcite/adapter/mongodb/MongoAdapterTest.java:22:
 error: cannot find symbol
[ERROR] import org.apache.calcite.test.CalciteAssert;
[ERROR]   ^
[ERROR]   symbol:   class CalciteAssert
[ERROR]   location: package org.apache.calcite.test
[ERROR] 
/home/jhyde/open1/calcite.4/mongodb/src/test/java/org/apache/calcite/adapter/mongodb/MongoAdapterTest.java:137:
 error: package CalciteAssert does not exist
[ERROR]   private CalciteAssert.AssertThat assertModel(String model) {
[ERROR]^
[ERROR] 
/home/jhyde/open1/calcite.4/mongodb/src/test/java/org/apache/calcite/adapter/mongodb/MongoAdapterTest.java:145:
 error: package CalciteAssert does not exist
[ERROR]   private CalciteAssert.AssertThat assertModel(URL url) {
[ERROR]^
[ERROR] 
/home/jhyde/open1/calcite.4/mongodb/src/test/java/org/apache/calcite/test/MongoAssertions.java:43:
 error: reference not found
[ERROR]   /** Similar to {@link CalciteAssert#checkResultUnordered}, but 
filters strings
[ERROR] ^



> On Jun 22, 2018, at 3:46 PM, Andrei Sereda  wrote:
> 
> Hmm. Both master and c12cb4b0de work for me. Perhaps the issue is JDK 8 vs
> 9 ?
> 
> # JDK8 (oracle) /  macOS
> $ mvn clean -DskipTests site
> 
> On Fri, Jun 22, 2018 at 5:56 PM Julian Hyde  wrote:
> 
>> I just tried it again. The following fails for me (jdk9, ubuntu):
>> 
>> $ git checkout c12cb4b0de
>> $ mvn clean -DskipTests site
>> 
>> Constructing Javadoc information...
>> 1 error
>> [INFO]
>> 
>> [INFO] Reactor Summary:
>> [INFO]
>> [INFO] Calcite 1.17.0-SNAPSHOT  FAILURE [02:29
>> min]
>> [INFO] Calcite Linq4j . SKIPPED
>> [INFO] Calcite Core ... SKIPPED
>> [INFO] Calcite Cassandra .. SKIPPED
>> [INFO] Calcite Druid .. SKIPPED
>> [INFO] Calcite Elasticsearch .. SKIPPED
>> [INFO] Calcite Elasticsearch5 . SKIPPED
>> [INFO] Calcite Examples ... SKIPPED
>> [INFO] Calcite Example CSV  SKIPPED
>> [INFO] Calcite Example Function ... SKIPPED
>> [INFO] Calcite File ... SKIPPED
>> [INFO] Calcite Geode .. SKIPPED
>> [INFO] Calcite MongoDB  SKIPPED
>> [INFO] Calcite Pig  SKIPPED
>> [INFO] Calcite Piglet . SKIPPED
>> [INFO] Calcite Plus ... SKIPPED
>> [INFO] Calcite Server . SKIPPED
>> [INFO] Calcite Spark .. SKIPPED
>> [INFO] Calcite Splunk . SKIPPED
>> [INFO] Calcite Ubenchmark 1.17.0-SNAPSHOT . SKIPPED
>> [INFO]
>> 
>> [INFO] BUILD FAILURE
>> [INFO]
>> 
>> [INFO] Total time: 02:29 min
>> [INFO] Finished at: 2018-06-22T14:53:13-07:00
>> [INFO]
>> 
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
>> project calcite: Error generating maven-javadoc-plugin:3.0.1:test-aggregate
>> report:
>> [ERROR] Exit code: 1 -
>> /home/jhyde/open1/calcite.4/elasticsearch2/src/test/java/org/apache/calcite/adapter/elasticsearch2/EmbeddedElasticNode.java:29:
>> error: package org.elasticsearch.node.internal does not exist
>> [ERROR] import org.elasticsearch.node.internal.InternalSettingsPreparer;
>> [ERROR]   ^
>> [ERROR]
>> [ERROR] Command line was: /usr/lib/jvm/jdk9/bin/javadoc @options @packages
>> @argfile
>> [ERROR]
>> [ERROR] Refer to the generated Javadoc files in
>> '/home/jhyde/open1/calcite.4/target/site/testapidocs' dir.
>> [ERROR] -> [Help 1]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with the
>> -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>> 
>> 
>>> On Jun 22, 

Re: [2/2] calcite git commit: [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of ES adapter (Andrei Sereda)

[Andrei Sereda]

Hmm. Both master and c12cb4b0de work for me. Perhaps the issue is JDK 8 vs
9 ?

# JDK8 (oracle) /  macOS
$ mvn clean -DskipTests site

On Fri, Jun 22, 2018 at 5:56 PM Julian Hyde  wrote:

> I just tried it again. The following fails for me (jdk9, ubuntu):
>
> $ git checkout c12cb4b0de
> $ mvn clean -DskipTests site
>
> Constructing Javadoc information...
> 1 error
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Calcite 1.17.0-SNAPSHOT  FAILURE [02:29
> min]
> [INFO] Calcite Linq4j . SKIPPED
> [INFO] Calcite Core ... SKIPPED
> [INFO] Calcite Cassandra .. SKIPPED
> [INFO] Calcite Druid .. SKIPPED
> [INFO] Calcite Elasticsearch .. SKIPPED
> [INFO] Calcite Elasticsearch5 . SKIPPED
> [INFO] Calcite Examples ... SKIPPED
> [INFO] Calcite Example CSV  SKIPPED
> [INFO] Calcite Example Function ... SKIPPED
> [INFO] Calcite File ... SKIPPED
> [INFO] Calcite Geode .. SKIPPED
> [INFO] Calcite MongoDB  SKIPPED
> [INFO] Calcite Pig  SKIPPED
> [INFO] Calcite Piglet . SKIPPED
> [INFO] Calcite Plus ... SKIPPED
> [INFO] Calcite Server . SKIPPED
> [INFO] Calcite Spark .. SKIPPED
> [INFO] Calcite Splunk . SKIPPED
> [INFO] Calcite Ubenchmark 1.17.0-SNAPSHOT . SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 02:29 min
> [INFO] Finished at: 2018-06-22T14:53:13-07:00
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
> project calcite: Error generating maven-javadoc-plugin:3.0.1:test-aggregate
> report:
> [ERROR] Exit code: 1 -
> /home/jhyde/open1/calcite.4/elasticsearch2/src/test/java/org/apache/calcite/adapter/elasticsearch2/EmbeddedElasticNode.java:29:
> error: package org.elasticsearch.node.internal does not exist
> [ERROR] import org.elasticsearch.node.internal.InternalSettingsPreparer;
> [ERROR]   ^
> [ERROR]
> [ERROR] Command line was: /usr/lib/jvm/jdk9/bin/javadoc @options @packages
> @argfile
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/jhyde/open1/calcite.4/target/site/testapidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>
>
> > On Jun 22, 2018, at 2:41 PM, Michael Mior  wrote:
> >
> > Odd, mvn clean site still works fine for me.
> > --
> > Michael Mior
> > mm...@apache.org
> >
> >
> >
> > Le ven. 22 juin 2018 à 17:12, Julian Hyde  a écrit :
> >
> >> Looks like this change broke “mvn site” (perhaps also “mvn
> >> javadoc:test-javadoc”).
> >>
> >> [ERROR] Failed to execute goal
> >> org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
> >> project calcite: Error generating
> maven-javadoc-plugin:3.0.1:test-aggregate
> >> report:
> >> [ERROR] Exit code: 1 -
> >>
> /home/jhyde/regress/calcite/elasticsearch2/src/test/java/org/apache/calcite/adapter/elasticsearch2/EmbeddedElasticNode.java:29:
> >> error: package org.elasticsearch.node.internal does not exist
> >> [ERROR] import org.elasticsearch.node.internal.InternalSettingsPreparer;
> >> [ERROR]   ^
> >> [ERROR]
> >>
> >>> On Jun 21, 2018, at 3:39 AM, mm...@apache.org wrote:
> >>>
> >>> [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of
> >> ES adapter (Andrei Sereda)
> >>>
> >>> After discussion on dev-list Integration tests (for ES) have been
> >> removed. They're now
> >>> superseded by unit tests (which execute queries against a real elastic
> >> instance)
> >>>
> >>> Added local file (zips-mini.json) which contains a small subset of
> >> original zips.json
> >>> (allows to bootstrap tests faster)
> >>>
> >>> Created separate ES JUnit rule which can be re-used across different
> >> tests.
> >>>
> >>> Both v2 and v5 of ES adapters are supported.
> 

Re: [2/2] calcite git commit: [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of ES adapter (Andrei Sereda)

[Andrei Sereda]

Travis doesn't invoke javadoc
:
# Print the Maven version, *skip tests and javadoc*
$DOCKERRUN $IMAGE mvn install -DskipTests=true -Dmaven.javadoc.skip=true
-Djavax.net.ssl.trustStorePassword=changeit -B -V




On Fri, Jun 22, 2018 at 5:14 PM Christian Beikov 
wrote:

> Huh? How is that possible? I thought the checks that are run by the
> Travis CI build catch these kinds of errors.
>
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 22.06.2018 um 23:11 schrieb Julian Hyde:
> > Looks like this change broke “mvn site” (perhaps also “mvn
> javadoc:test-javadoc”).
> >
> > [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
> project calcite: Error generating maven-javadoc-plugin:3.0.1:test-aggregate
> report:
> > [ERROR] Exit code: 1 -
> /home/jhyde/regress/calcite/elasticsearch2/src/test/java/org/apache/calcite/adapter/elasticsearch2/EmbeddedElasticNode.java:29:
> error: package org.elasticsearch.node.internal does not exist
> > [ERROR] import org.elasticsearch.node.internal.InternalSettingsPreparer;
> > [ERROR]   ^
> > [ERROR]
> >
> >> On Jun 21, 2018, at 3:39 AM, mm...@apache.org wrote:
> >>
> >> [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of
> ES adapter (Andrei Sereda)
> >>
> >> After discussion on dev-list Integration tests (for ES) have been
> removed. They're now
> >> superseded by unit tests (which execute queries against a real elastic
> instance)
> >>
> >> Added local file (zips-mini.json) which contains a small subset of
> original zips.json
> >> (allows to bootstrap tests faster)
> >>
> >> Created separate ES JUnit rule which can be re-used across different
> tests.
> >>
> >> Both v2 and v5 of ES adapters are supported.
> >>
> >> Close apache/calcite#716
> >>
> >>
> >> Project: http://git-wip-us.apache.org/repos/asf/calcite/repo
> >> Commit: http://git-wip-us.apache.org/repos/asf/calcite/commit/c12cb4b0
> >> Tree: http://git-wip-us.apache.org/repos/asf/calcite/tree/c12cb4b0
> >> Diff: http://git-wip-us.apache.org/repos/asf/calcite/diff/c12cb4b0
> >>
> >> Branch: refs/heads/master
> >> Commit: c12cb4b0de1baa3f7cbb9952ee350fdd1701662d
> >> Parents: 37944bb
> >> Author: Andrei Sereda 
> >> Authored: Thu May 31 18:19:10 2018 -0400
> >> Committer: Michael Mior 
> >> Committed: Thu Jun 21 06:38:50 2018 -0400
> >>
> >> --
> >> .../AbstractElasticsearchTable.java |  12 +
> >> .../elasticsearch/ElasticsearchProject.java |  61 ++-
> >> elasticsearch2/pom.xml  |   6 +
> >> .../Elasticsearch2Enumerator.java   |  12 +-
> >> .../elasticsearch2/Elasticsearch2Schema.java|  16 +-
> >> .../elasticsearch2/Elasticsearch2Table.java |   9 +-
> >> .../ElasticSearch2AdapterTest.java  | 395 ++
> >> .../elasticsearch2/EmbeddedElasticNode.java | 147 +++
> >> .../elasticsearch2/EmbeddedElasticRule.java |  97 +
> >> .../org/apache/calcite/test/ElasticChecker.java |  49 +++
> >> .../calcite/test/Elasticsearch2AdapterIT.java   | 270 -
> >> .../resources/elasticsearch-zips-model.json |  50 ---
> >> .../src/test/resources/zips-mini.json   | 149 +++
> >> elasticsearch5/pom.xml  |  31 ++
> >> .../elasticsearch5/Elasticsearch5Schema.java|  17 +-
> >> .../elasticsearch5/Elasticsearch5Table.java |  11 +-
> >> .../ElasticSearch5AdapterTest.java  | 399
> +++
> >> .../elasticsearch5/EmbeddedElasticNode.java | 153 +++
> >> .../elasticsearch5/EmbeddedElasticRule.java |  98 +
> >> .../org/apache/calcite/test/ElasticChecker.java |  49 +++
> >> .../calcite/test/Elasticsearch5AdapterIT.java   | 270 -
> >> .../resources/elasticsearch-zips-model.json |  50 ---
> >> elasticsearch5/src/test/resources/log4j2.xml|  16 +
> >> .../src/test/resources/zips-mini.json   | 149 +++
> >> pom.xml |  20 +-
> >> 25 files changed, 1866 insertions(+), 670 deletions(-)
> >> --
> >>
> >>
> >>
> http://git-wip-us.apache.org/repos/asf/calcite/blob/c12cb4b0/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
> >> --
> >> diff --git
> a/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
> b/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
> >> index 0980469..8cc5933 100644
> >> ---
> a/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
> >> +++
> 

Re: [2/2] calcite git commit: [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of ES adapter (Andrei Sereda)

[Julian Hyde]

I just tried it again. The following fails for me (jdk9, ubuntu):

$ git checkout c12cb4b0de
$ mvn clean -DskipTests site 

Constructing Javadoc information...
1 error
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Calcite 1.17.0-SNAPSHOT  FAILURE [02:29 min]
[INFO] Calcite Linq4j . SKIPPED
[INFO] Calcite Core ... SKIPPED
[INFO] Calcite Cassandra .. SKIPPED
[INFO] Calcite Druid .. SKIPPED
[INFO] Calcite Elasticsearch .. SKIPPED
[INFO] Calcite Elasticsearch5 . SKIPPED
[INFO] Calcite Examples ... SKIPPED
[INFO] Calcite Example CSV  SKIPPED
[INFO] Calcite Example Function ... SKIPPED
[INFO] Calcite File ... SKIPPED
[INFO] Calcite Geode .. SKIPPED
[INFO] Calcite MongoDB  SKIPPED
[INFO] Calcite Pig  SKIPPED
[INFO] Calcite Piglet . SKIPPED
[INFO] Calcite Plus ... SKIPPED
[INFO] Calcite Server . SKIPPED
[INFO] Calcite Spark .. SKIPPED
[INFO] Calcite Splunk . SKIPPED
[INFO] Calcite Ubenchmark 1.17.0-SNAPSHOT . SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 02:29 min
[INFO] Finished at: 2018-06-22T14:53:13-07:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on project 
calcite: Error generating maven-javadoc-plugin:3.0.1:test-aggregate report: 
[ERROR] Exit code: 1 - 
/home/jhyde/open1/calcite.4/elasticsearch2/src/test/java/org/apache/calcite/adapter/elasticsearch2/EmbeddedElasticNode.java:29:
 error: package org.elasticsearch.node.internal does not exist
[ERROR] import org.elasticsearch.node.internal.InternalSettingsPreparer;
[ERROR]   ^
[ERROR] 
[ERROR] Command line was: /usr/lib/jvm/jdk9/bin/javadoc @options @packages 
@argfile
[ERROR] 
[ERROR] Refer to the generated Javadoc files in 
'/home/jhyde/open1/calcite.4/target/site/testapidocs' dir.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException


> On Jun 22, 2018, at 2:41 PM, Michael Mior  wrote:
> 
> Odd, mvn clean site still works fine for me.
> --
> Michael Mior
> mm...@apache.org
> 
> 
> 
> Le ven. 22 juin 2018 à 17:12, Julian Hyde  a écrit :
> 
>> Looks like this change broke “mvn site” (perhaps also “mvn
>> javadoc:test-javadoc”).
>> 
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
>> project calcite: Error generating maven-javadoc-plugin:3.0.1:test-aggregate
>> report:
>> [ERROR] Exit code: 1 -
>> /home/jhyde/regress/calcite/elasticsearch2/src/test/java/org/apache/calcite/adapter/elasticsearch2/EmbeddedElasticNode.java:29:
>> error: package org.elasticsearch.node.internal does not exist
>> [ERROR] import org.elasticsearch.node.internal.InternalSettingsPreparer;
>> [ERROR]   ^
>> [ERROR]
>> 
>>> On Jun 21, 2018, at 3:39 AM, mm...@apache.org wrote:
>>> 
>>> [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of
>> ES adapter (Andrei Sereda)
>>> 
>>> After discussion on dev-list Integration tests (for ES) have been
>> removed. They're now
>>> superseded by unit tests (which execute queries against a real elastic
>> instance)
>>> 
>>> Added local file (zips-mini.json) which contains a small subset of
>> original zips.json
>>> (allows to bootstrap tests faster)
>>> 
>>> Created separate ES JUnit rule which can be re-used across different
>> tests.
>>> 
>>> Both v2 and v5 of ES adapters are supported.
>>> 
>>> Close apache/calcite#716
>>> 
>>> 
>>> Project: http://git-wip-us.apache.org/repos/asf/calcite/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/calcite/commit/c12cb4b0
>>> Tree: http://git-wip-us.apache.org/repos/asf/calcite/tree/c12cb4b0
>>> Diff: http://git-wip-us.apache.org/repos/asf/calcite/diff/c12cb4b0
>>> 
>>> Branch: refs/heads/master
>>> Commit: 

Re: [2/2] calcite git commit: [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of ES adapter (Andrei Sereda)

[Michael Mior]

Odd, mvn clean site still works fine for me.
--
Michael Mior
mm...@apache.org



Le ven. 22 juin 2018 à 17:12, Julian Hyde  a écrit :

> Looks like this change broke “mvn site” (perhaps also “mvn
> javadoc:test-javadoc”).
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on
> project calcite: Error generating maven-javadoc-plugin:3.0.1:test-aggregate
> report:
> [ERROR] Exit code: 1 -
> /home/jhyde/regress/calcite/elasticsearch2/src/test/java/org/apache/calcite/adapter/elasticsearch2/EmbeddedElasticNode.java:29:
> error: package org.elasticsearch.node.internal does not exist
> [ERROR] import org.elasticsearch.node.internal.InternalSettingsPreparer;
> [ERROR]   ^
> [ERROR]
>
> > On Jun 21, 2018, at 3:39 AM, mm...@apache.org wrote:
> >
> > [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of
> ES adapter (Andrei Sereda)
> >
> > After discussion on dev-list Integration tests (for ES) have been
> removed. They're now
> > superseded by unit tests (which execute queries against a real elastic
> instance)
> >
> > Added local file (zips-mini.json) which contains a small subset of
> original zips.json
> > (allows to bootstrap tests faster)
> >
> > Created separate ES JUnit rule which can be re-used across different
> tests.
> >
> > Both v2 and v5 of ES adapters are supported.
> >
> > Close apache/calcite#716
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/calcite/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/calcite/commit/c12cb4b0
> > Tree: http://git-wip-us.apache.org/repos/asf/calcite/tree/c12cb4b0
> > Diff: http://git-wip-us.apache.org/repos/asf/calcite/diff/c12cb4b0
> >
> > Branch: refs/heads/master
> > Commit: c12cb4b0de1baa3f7cbb9952ee350fdd1701662d
> > Parents: 37944bb
> > Author: Andrei Sereda 
> > Authored: Thu May 31 18:19:10 2018 -0400
> > Committer: Michael Mior 
> > Committed: Thu Jun 21 06:38:50 2018 -0400
> >
> > --
> > .../AbstractElasticsearchTable.java |  12 +
> > .../elasticsearch/ElasticsearchProject.java |  61 ++-
> > elasticsearch2/pom.xml  |   6 +
> > .../Elasticsearch2Enumerator.java   |  12 +-
> > .../elasticsearch2/Elasticsearch2Schema.java|  16 +-
> > .../elasticsearch2/Elasticsearch2Table.java |   9 +-
> > .../ElasticSearch2AdapterTest.java  | 395 ++
> > .../elasticsearch2/EmbeddedElasticNode.java | 147 +++
> > .../elasticsearch2/EmbeddedElasticRule.java |  97 +
> > .../org/apache/calcite/test/ElasticChecker.java |  49 +++
> > .../calcite/test/Elasticsearch2AdapterIT.java   | 270 -
> > .../resources/elasticsearch-zips-model.json |  50 ---
> > .../src/test/resources/zips-mini.json   | 149 +++
> > elasticsearch5/pom.xml  |  31 ++
> > .../elasticsearch5/Elasticsearch5Schema.java|  17 +-
> > .../elasticsearch5/Elasticsearch5Table.java |  11 +-
> > .../ElasticSearch5AdapterTest.java  | 399 +++
> > .../elasticsearch5/EmbeddedElasticNode.java | 153 +++
> > .../elasticsearch5/EmbeddedElasticRule.java |  98 +
> > .../org/apache/calcite/test/ElasticChecker.java |  49 +++
> > .../calcite/test/Elasticsearch5AdapterIT.java   | 270 -
> > .../resources/elasticsearch-zips-model.json |  50 ---
> > elasticsearch5/src/test/resources/log4j2.xml|  16 +
> > .../src/test/resources/zips-mini.json   | 149 +++
> > pom.xml |  20 +-
> > 25 files changed, 1866 insertions(+), 670 deletions(-)
> > --
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/calcite/blob/c12cb4b0/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
> > --
> > diff --git
> a/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
> b/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
> > index 0980469..8cc5933 100644
> > ---
> a/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
> > +++
> b/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
> > @@ -75,6 +75,18 @@ public abstract class AbstractElasticsearchTable
> extends AbstractQueryableTable
> > relOptTable, this, null);
> >   }
> >
> > +  /**
> > +   * In ES 5.x scripted fields start with {@code params._source.foo}
> while in ES2.x
> > +   * {@code _source.foo}. Helper method to build correct query based on
> runtime version of elastic.
> > +   *
> > +   * @see https://github.com/elastic/elasticsearch/issues/20068;>_source
> variable
> > +   * @see 

Re: [2/2] calcite git commit: [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of ES adapter (Andrei Sereda)

[Christian Beikov]

Huh? How is that possible? I thought the checks that are run by the 
Travis CI build catch these kinds of errors.



Mit freundlichen Grüßen,

*Christian Beikov*
Am 22.06.2018 um 23:11 schrieb Julian Hyde:

Looks like this change broke “mvn site” (perhaps also “mvn 
javadoc:test-javadoc”).

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on project 
calcite: Error generating maven-javadoc-plugin:3.0.1:test-aggregate report:
[ERROR] Exit code: 1 - 
/home/jhyde/regress/calcite/elasticsearch2/src/test/java/org/apache/calcite/adapter/elasticsearch2/EmbeddedElasticNode.java:29:
 error: package org.elasticsearch.node.internal does not exist
[ERROR] import org.elasticsearch.node.internal.InternalSettingsPreparer;
[ERROR]   ^
[ERROR]


On Jun 21, 2018, at 3:39 AM, mm...@apache.org wrote:

[CALCITE-2347] running ElasticSearch in embedded mode for unit tests of ES 
adapter (Andrei Sereda)

After discussion on dev-list Integration tests (for ES) have been removed. 
They're now
superseded by unit tests (which execute queries against a real elastic instance)

Added local file (zips-mini.json) which contains a small subset of original 
zips.json
(allows to bootstrap tests faster)

Created separate ES JUnit rule which can be re-used across different tests.

Both v2 and v5 of ES adapters are supported.

Close apache/calcite#716


Project: http://git-wip-us.apache.org/repos/asf/calcite/repo
Commit: http://git-wip-us.apache.org/repos/asf/calcite/commit/c12cb4b0
Tree: http://git-wip-us.apache.org/repos/asf/calcite/tree/c12cb4b0
Diff: http://git-wip-us.apache.org/repos/asf/calcite/diff/c12cb4b0

Branch: refs/heads/master
Commit: c12cb4b0de1baa3f7cbb9952ee350fdd1701662d
Parents: 37944bb
Author: Andrei Sereda 
Authored: Thu May 31 18:19:10 2018 -0400
Committer: Michael Mior 
Committed: Thu Jun 21 06:38:50 2018 -0400

--
.../AbstractElasticsearchTable.java |  12 +
.../elasticsearch/ElasticsearchProject.java |  61 ++-
elasticsearch2/pom.xml  |   6 +
.../Elasticsearch2Enumerator.java   |  12 +-
.../elasticsearch2/Elasticsearch2Schema.java|  16 +-
.../elasticsearch2/Elasticsearch2Table.java |   9 +-
.../ElasticSearch2AdapterTest.java  | 395 ++
.../elasticsearch2/EmbeddedElasticNode.java | 147 +++
.../elasticsearch2/EmbeddedElasticRule.java |  97 +
.../org/apache/calcite/test/ElasticChecker.java |  49 +++
.../calcite/test/Elasticsearch2AdapterIT.java   | 270 -
.../resources/elasticsearch-zips-model.json |  50 ---
.../src/test/resources/zips-mini.json   | 149 +++
elasticsearch5/pom.xml  |  31 ++
.../elasticsearch5/Elasticsearch5Schema.java|  17 +-
.../elasticsearch5/Elasticsearch5Table.java |  11 +-
.../ElasticSearch5AdapterTest.java  | 399 +++
.../elasticsearch5/EmbeddedElasticNode.java | 153 +++
.../elasticsearch5/EmbeddedElasticRule.java |  98 +
.../org/apache/calcite/test/ElasticChecker.java |  49 +++
.../calcite/test/Elasticsearch5AdapterIT.java   | 270 -
.../resources/elasticsearch-zips-model.json |  50 ---
elasticsearch5/src/test/resources/log4j2.xml|  16 +
.../src/test/resources/zips-mini.json   | 149 +++
pom.xml |  20 +-
25 files changed, 1866 insertions(+), 670 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/calcite/blob/c12cb4b0/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
--
diff --git 
a/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
 
b/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
index 0980469..8cc5933 100644
--- 
a/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
+++ 
b/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
@@ -75,6 +75,18 @@ public abstract class AbstractElasticsearchTable extends 
AbstractQueryableTable
 relOptTable, this, null);
   }

+  /**
+   * In ES 5.x scripted fields start with {@code params._source.foo} while in 
ES2.x
+   * {@code _source.foo}. Helper method to build correct query based on 
runtime version of elastic.
+   *
+   * @see https://github.com/elastic/elasticsearch/issues/20068;>_source 
variable
+   * @see https://www.elastic.co/guide/en/elasticsearch/reference/master/modules-scripting-fields.html;>Scripted
 Fields
+   */
+  protected String scriptedFieldPrefix() {
+// this is default pattern starting 5.x
+

Re: [2/2] calcite git commit: [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of ES adapter (Andrei Sereda)

[Julian Hyde]

Looks like this change broke “mvn site” (perhaps also “mvn 
javadoc:test-javadoc”).

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on project 
calcite: Error generating maven-javadoc-plugin:3.0.1:test-aggregate report: 
[ERROR] Exit code: 1 - 
/home/jhyde/regress/calcite/elasticsearch2/src/test/java/org/apache/calcite/adapter/elasticsearch2/EmbeddedElasticNode.java:29:
 error: package org.elasticsearch.node.internal does not exist
[ERROR] import org.elasticsearch.node.internal.InternalSettingsPreparer;
[ERROR]   ^
[ERROR] 

> On Jun 21, 2018, at 3:39 AM, mm...@apache.org wrote:
> 
> [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of ES 
> adapter (Andrei Sereda)
> 
> After discussion on dev-list Integration tests (for ES) have been removed. 
> They're now
> superseded by unit tests (which execute queries against a real elastic 
> instance)
> 
> Added local file (zips-mini.json) which contains a small subset of original 
> zips.json
> (allows to bootstrap tests faster)
> 
> Created separate ES JUnit rule which can be re-used across different tests.
> 
> Both v2 and v5 of ES adapters are supported.
> 
> Close apache/calcite#716
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/calcite/repo
> Commit: http://git-wip-us.apache.org/repos/asf/calcite/commit/c12cb4b0
> Tree: http://git-wip-us.apache.org/repos/asf/calcite/tree/c12cb4b0
> Diff: http://git-wip-us.apache.org/repos/asf/calcite/diff/c12cb4b0
> 
> Branch: refs/heads/master
> Commit: c12cb4b0de1baa3f7cbb9952ee350fdd1701662d
> Parents: 37944bb
> Author: Andrei Sereda 
> Authored: Thu May 31 18:19:10 2018 -0400
> Committer: Michael Mior 
> Committed: Thu Jun 21 06:38:50 2018 -0400
> 
> --
> .../AbstractElasticsearchTable.java |  12 +
> .../elasticsearch/ElasticsearchProject.java |  61 ++-
> elasticsearch2/pom.xml  |   6 +
> .../Elasticsearch2Enumerator.java   |  12 +-
> .../elasticsearch2/Elasticsearch2Schema.java|  16 +-
> .../elasticsearch2/Elasticsearch2Table.java |   9 +-
> .../ElasticSearch2AdapterTest.java  | 395 ++
> .../elasticsearch2/EmbeddedElasticNode.java | 147 +++
> .../elasticsearch2/EmbeddedElasticRule.java |  97 +
> .../org/apache/calcite/test/ElasticChecker.java |  49 +++
> .../calcite/test/Elasticsearch2AdapterIT.java   | 270 -
> .../resources/elasticsearch-zips-model.json |  50 ---
> .../src/test/resources/zips-mini.json   | 149 +++
> elasticsearch5/pom.xml  |  31 ++
> .../elasticsearch5/Elasticsearch5Schema.java|  17 +-
> .../elasticsearch5/Elasticsearch5Table.java |  11 +-
> .../ElasticSearch5AdapterTest.java  | 399 +++
> .../elasticsearch5/EmbeddedElasticNode.java | 153 +++
> .../elasticsearch5/EmbeddedElasticRule.java |  98 +
> .../org/apache/calcite/test/ElasticChecker.java |  49 +++
> .../calcite/test/Elasticsearch5AdapterIT.java   | 270 -
> .../resources/elasticsearch-zips-model.json |  50 ---
> elasticsearch5/src/test/resources/log4j2.xml|  16 +
> .../src/test/resources/zips-mini.json   | 149 +++
> pom.xml |  20 +-
> 25 files changed, 1866 insertions(+), 670 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/calcite/blob/c12cb4b0/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
> --
> diff --git 
> a/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
>  
> b/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
> index 0980469..8cc5933 100644
> --- 
> a/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
> +++ 
> b/core/src/main/java/org/apache/calcite/adapter/elasticsearch/AbstractElasticsearchTable.java
> @@ -75,6 +75,18 @@ public abstract class AbstractElasticsearchTable extends 
> AbstractQueryableTable
> relOptTable, this, null);
>   }
> 
> +  /**
> +   * In ES 5.x scripted fields start with {@code params._source.foo} while 
> in ES2.x
> +   * {@code _source.foo}. Helper method to build correct query based on 
> runtime version of elastic.
> +   *
> +   * @see  href="https://github.com/elastic/elasticsearch/issues/20068;>_source 
> variable
> +   * @see  href="https://www.elastic.co/guide/en/elasticsearch/reference/master/modules-scripting-fields.html;>Scripted
>  Fields
> +   */
> +  protected String scriptedFieldPrefix() {
> +// this is default pattern starting 5.x
> +return "params._source";
> +  }
> +
>   /** Executes a "find" operation on the 

Re: ElasticSearch use of rest client (instead of TransportClient)

[Christian Beikov]

Looks great!


Mit freundlichen Grüßen,

*Christian Beikov*
Am 22.06.2018 um 20:24 schrieb Michael Mior:

Looks good to me but I'll defer to Christian since I know little about ES.
Thanks for this Andrei!
--
Michael Mior
mm...@apache.org



Le ven. 22 juin 2018 à 14:13, Andrei Sereda  a écrit :


CALCITE-2376 

Please let me know if you agree with the plan

On Fri, Jun 22, 2018 at 1:47 PM Christian Beikov <
christian.bei...@gmail.com>
wrote:


The original reason for having separate adapters was because the ES
Java-Client SDKs require different library versions which aren't binary
compatible. Having separate modules just seemed to be the simplest
solution. If you can make sure this is not going to be a problem for
users, I'd be all for unifying the adapters. Changing the dependency and
the schema factory name are IMO not problematic.


Mit freundlichen Grüßen,

*Christian Beikov*
Am 22.06.2018 um 19:07 schrieb Andrei Sereda:

1) If we go single (and separate) ES adapter route, people will have to
change their existing maven dependencies as well as ES schema

configuration

(at least SchemaFactory name). I'm not sure if there are any explicit

(or

implicit) backwards compatibility policies in calcite. There are

(albeit)

small implications for end-user.

On Fri, Jun 22, 2018 at 12:54 PM Michael Mior 

wrote:

1) I personally would be open to this unless there's strong evidence

of

use

of the ES2 adapter.

2) Calcite already depends on Jackson in core and both ES modules, so

this

isn't a concern.
--
Michael Mior
mm...@apache.org



Le ven. 22 juin 2018 à 12:37, Andrei Sereda  a

écrit

:

Some questions regarding this change:

1) Should one remove ES2 and ES5 adapters (maven modules) in favor of
single one: just ES ? This will be backwards incompatible change. Or

keep

them as is and create a new module ? There is also quite a bit of ES
related code in calcite-core.

2) Since I need to create / parse JSON formats, ES adapter would have

to

depend on some JSON library (most likely existing Jackson). Is that
acceptable ?



On Fri, May 18, 2018 at 4:29 PM Andrei Sereda 

wrote:

I believe this shouldn't be an issue with http client (contrary to

native

transport)

On Fri, May 18, 2018, 16:16 Christian Beikov <

christian.bei...@gmail.com

wrote:


That's mainly because the Java drivers changed in a way that made
impossible to use the same adapter. I might be wrong, but I think

the

ES5 adapter doesn't work with an ES2 server instance just like the

ES2

adapter doesn't work with an ES5+ server instance.

If all of this could just go away, that would be great :)


Mit freundlichen Grüßen,




*Christian Beikov*
Am 18.05.2018 um 21:19 schrieb Andrei Sereda:

Yes it should be, since it is just an http client (apache http).
ElasticSearch Rest API (query API) didn't change much
<

https://www.elastic.co/guide/en/elasticsearch/reference/5.0/breaking-changes-5.0.html

.

Next question would be : why there is a need in two separate

modules

elasticsearch2 and elasticsearch5

On Fri, May 18, 2018 at 3:11 PM, Christian Beikov <
christian.bei...@gmail.com> wrote:


Hey Andrei,

that would be awesome! Do you know by any chance if the low level

client

is also compatible with older ES versions?


Mit freundlichen Grüßen,




*Christian Beikov*
Am 18.05.2018 um 20:45 schrieb Andrei Sereda:


Hello,

ES TransportClient is deprecated in 7.0 (to be removed

in 8.0) in favor of http rest client(s). Would you consider a

contribution

switching to Rest Low-Level Client
(which
has much fewer dependencies) ?


Thanks,
Andrei.

Calcite-Master - Build # 310 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Calcite-Master (build #310)

Status: Still Failing

Check console output at https://builds.apache.org/job/Calcite-Master/310/ to 
view the results.

Calcite-Master - Build # 309 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Calcite-Master (build #309)

Status: Still Failing

Check console output at https://builds.apache.org/job/Calcite-Master/309/ to 
view the results.

Re: Gandiva

[Julian Hyde]

Suppose a company wishes to build a graph database using their own innovative 
graph index data structure. They nevertheless need to implement core relational 
algebra, core data types, and core built-in functions (+, CASE, SUM, 
SUBSTRING). And they want to implement these on a memory-efficient data 
structure (tens of thousands of rows, stored column-oriented, per memory 
block). This is a massive effort.

With Calcite+Gandiva+Arrow they just need to create a sequence of relational 
operators (using RelBuilder, say) and efficient machine code is generated. They 
can then start adding their own data types, built-in functions, and relational 
operators, using the same architecture.

Julian


> On Jun 22, 2018, at 11:33 AM, Xiening Dai  wrote:
> 
> I was in a talk regarding Gandiva yesterday. Impressive work!
> 
> But I am not sure why Calcite would like to integrate with it. To me Gandiva 
> is on execution side, in which scenarios a query planner would need a arrow 
> engine? I read the original Jira about implementing file enumerator, but the 
> intent is still not clear to me. Would appreciate if you can elaborate. 
> Thanks.
> 
> 
>> On Jun 22, 2018, at 11:20 AM, Julian Hyde  wrote:
>> 
>> There is a discussion on dev@arrow about Gandiva, a kernel for Arrow[1].
>> 
>> I think it would be an interesting library on which to build our Arrow 
>> engine. (Without a kernel, Arrow is just a data format, but with Gandiva it 
>> becomes an engine upon which we can implement all relational operations, 
>> albeit on a multi-threaded single node. Potentially this approach can 
>> process each row in a few machine cycles, i.e. billions of records per 
>> second. Therefore single-node would be sufficient for many queries.)
>> 
>> Masayuki Takahashi has started to develop an Arrow adapter for Calcite[2], 
>> but a lot of work remains to implement all SQL built-in functions and basic 
>> relational operators. Building on top of Gandiva we could save a lot of this 
>> effort.
>> 
>> Julian
>> 
>> [1] 
>> https://lists.apache.org/thread.html/f099b3d1e2aaf9803c5c756f872a594baf17e9f25974e3496c9706d9@%3Cdev.arrow.apache.org%3E
>>  
>> 
>> 
>> [2] https://issues.apache.org/jira/browse/CALCITE-2173 
>> 
> 

Re: Gandiva

[Xiening Dai]

I was in a talk regarding Gandiva yesterday. Impressive work!

But I am not sure why Calcite would like to integrate with it. To me Gandiva is 
on execution side, in which scenarios a query planner would need a arrow 
engine? I read the original Jira about implementing file enumerator, but the 
intent is still not clear to me. Would appreciate if you can elaborate. Thanks.


> On Jun 22, 2018, at 11:20 AM, Julian Hyde  wrote:
> 
> There is a discussion on dev@arrow about Gandiva, a kernel for Arrow[1].
> 
> I think it would be an interesting library on which to build our Arrow 
> engine. (Without a kernel, Arrow is just a data format, but with Gandiva it 
> becomes an engine upon which we can implement all relational operations, 
> albeit on a multi-threaded single node. Potentially this approach can process 
> each row in a few machine cycles, i.e. billions of records per second. 
> Therefore single-node would be sufficient for many queries.)
> 
> Masayuki Takahashi has started to develop an Arrow adapter for Calcite[2], 
> but a lot of work remains to implement all SQL built-in functions and basic 
> relational operators. Building on top of Gandiva we could save a lot of this 
> effort.
> 
> Julian
> 
> [1] 
> https://lists.apache.org/thread.html/f099b3d1e2aaf9803c5c756f872a594baf17e9f25974e3496c9706d9@%3Cdev.arrow.apache.org%3E
>  
> 
> 
> [2] https://issues.apache.org/jira/browse/CALCITE-2173 
> 

Gandiva

[Julian Hyde]

There is a discussion on dev@arrow about Gandiva, a kernel for Arrow[1].

I think it would be an interesting library on which to build our Arrow engine. 
(Without a kernel, Arrow is just a data format, but with Gandiva it becomes an 
engine upon which we can implement all relational operations, albeit on a 
multi-threaded single node. Potentially this approach can process each row in a 
few machine cycles, i.e. billions of records per second. Therefore single-node 
would be sufficient for many queries.)

Masayuki Takahashi has started to develop an Arrow adapter for Calcite[2], but 
a lot of work remains to implement all SQL built-in functions and basic 
relational operators. Building on top of Gandiva we could save a lot of this 
effort.

Julian

[1] 
https://lists.apache.org/thread.html/f099b3d1e2aaf9803c5c756f872a594baf17e9f25974e3496c9706d9@%3Cdev.arrow.apache.org%3E
 


[2] https://issues.apache.org/jira/browse/CALCITE-2173 
 

Re: ElasticSearch use of rest client (instead of TransportClient)

[Andrei Sereda]

CALCITE-2376 

Please let me know if you agree with the plan

On Fri, Jun 22, 2018 at 1:47 PM Christian Beikov 
wrote:

> The original reason for having separate adapters was because the ES
> Java-Client SDKs require different library versions which aren't binary
> compatible. Having separate modules just seemed to be the simplest
> solution. If you can make sure this is not going to be a problem for
> users, I'd be all for unifying the adapters. Changing the dependency and
> the schema factory name are IMO not problematic.
>
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 22.06.2018 um 19:07 schrieb Andrei Sereda:
> > 1) If we go single (and separate) ES adapter route, people will have to
> > change their existing maven dependencies as well as ES schema
> configuration
> > (at least SchemaFactory name). I'm not sure if there are any explicit (or
> > implicit) backwards compatibility policies in calcite. There are (albeit)
> > small implications for end-user.
> >
> > On Fri, Jun 22, 2018 at 12:54 PM Michael Mior  wrote:
> >
> >> 1) I personally would be open to this unless there's strong evidence of
> use
> >> of the ES2 adapter.
> >>
> >> 2) Calcite already depends on Jackson in core and both ES modules, so
> this
> >> isn't a concern.
> >> --
> >> Michael Mior
> >> mm...@apache.org
> >>
> >>
> >>
> >> Le ven. 22 juin 2018 à 12:37, Andrei Sereda  a écrit
> :
> >>
> >>> Some questions regarding this change:
> >>>
> >>> 1) Should one remove ES2 and ES5 adapters (maven modules) in favor of
> >>> single one: just ES ? This will be backwards incompatible change. Or
> keep
> >>> them as is and create a new module ? There is also quite a bit of ES
> >>> related code in calcite-core.
> >>>
> >>> 2) Since I need to create / parse JSON formats, ES adapter would have
> to
> >>> depend on some JSON library (most likely existing Jackson). Is that
> >>> acceptable ?
> >>>
> >>>
> >>>
> >>> On Fri, May 18, 2018 at 4:29 PM Andrei Sereda 
> wrote:
> >>>
>  I believe this shouldn't be an issue with http client (contrary to
> >> native
>  transport)
> 
>  On Fri, May 18, 2018, 16:16 Christian Beikov <
> >> christian.bei...@gmail.com
>  wrote:
> 
> > That's mainly because the Java drivers changed in a way that made
> > impossible to use the same adapter. I might be wrong, but I think the
> > ES5 adapter doesn't work with an ES2 server instance just like the
> ES2
> > adapter doesn't work with an ES5+ server instance.
> >
> > If all of this could just go away, that would be great :)
> >
> >
> > Mit freundlichen Grüßen,
> >
> >> 
> > *Christian Beikov*
> > Am 18.05.2018 um 21:19 schrieb Andrei Sereda:
> >> Yes it should be, since it is just an http client (apache http).
> >> ElasticSearch Rest API (query API) didn't change much
> >> <
> >>
> https://www.elastic.co/guide/en/elasticsearch/reference/5.0/breaking-changes-5.0.html
> >> .
> >>
> >> Next question would be : why there is a need in two separate modules
> >> elasticsearch2 and elasticsearch5
> >>
> >> On Fri, May 18, 2018 at 3:11 PM, Christian Beikov <
> >> christian.bei...@gmail.com> wrote:
> >>
> >>> Hey Andrei,
> >>>
> >>> that would be awesome! Do you know by any chance if the low level
> > client
> >>> is also compatible with older ES versions?
> >>>
> >>>
> >>> Mit freundlichen Grüßen,
> >>>
> >> 
> >>> *Christian Beikov*
> >>> Am 18.05.2018 um 20:45 schrieb Andrei Sereda:
> >>>
>  Hello,
> 
>  ES TransportClient is deprecated in 7.0 (to be removed
>    pi/master/transport-client.html>
>  in 8.0) in favor of http rest client(s). Would you consider a
> > contribution
>  switching to Rest Low-Level Client
>    est/current/java-rest-low.html>(which
>  has much fewer dependencies) ?
> 
> 
>  Thanks,
>  Andrei.
> 
> 
> >
>
>

[jira] [Created] (CALCITE-2376) migrate elastic adapters to (low-level) rest client

[Andrei Sereda (JIRA)]

Andrei Sereda created CALCITE-2376:
--

 Summary: migrate elastic adapters to (low-level) rest client
 Key: CALCITE-2376
 URL: https://issues.apache.org/jira/browse/CALCITE-2376
 Project: Calcite
  Issue Type: Improvement
  Components: elasticsearch-adapter
Reporter: Andrei Sereda
Assignee: Julian Hyde


This is an effort to migrate existing Elastic Search adapters to use [low-level 
rest 
client|https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/java-rest-low.html].
 Existing [native transport 
client|https://www.elastic.co/guide/en/elasticsearch/client/java-api/6.3/client.html]
 has been deprecated in 7.0 (to be removed in 8.x).

Another advantage of low-level client is that it is compatible with any ES 
server version and has few (non-core) dependencies. Part of this improvement, 
both ES2 and ES5 adapters will be unified and reside under new maven module 
{{elasticsearch}} (contrary to separate {{elasticsearch2}} and 
{{elasticsearch5}}).
h3. Breaking changes

Using new {{artifactId}} and {{SchemaFactory}} implementation will force 
clients to change their configuration and dependencies. No other breaking 
changes are expected. 
  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: ElasticSearch use of rest client (instead of TransportClient)

[Christian Beikov]

The original reason for having separate adapters was because the ES 
Java-Client SDKs require different library versions which aren't binary 
compatible. Having separate modules just seemed to be the simplest 
solution. If you can make sure this is not going to be a problem for 
users, I'd be all for unifying the adapters. Changing the dependency and 
the schema factory name are IMO not problematic.



Mit freundlichen Grüßen,

*Christian Beikov*
Am 22.06.2018 um 19:07 schrieb Andrei Sereda:

1) If we go single (and separate) ES adapter route, people will have to
change their existing maven dependencies as well as ES schema configuration
(at least SchemaFactory name). I'm not sure if there are any explicit (or
implicit) backwards compatibility policies in calcite. There are (albeit)
small implications for end-user.

On Fri, Jun 22, 2018 at 12:54 PM Michael Mior  wrote:


1) I personally would be open to this unless there's strong evidence of use
of the ES2 adapter.

2) Calcite already depends on Jackson in core and both ES modules, so this
isn't a concern.
--
Michael Mior
mm...@apache.org



Le ven. 22 juin 2018 à 12:37, Andrei Sereda  a écrit :


Some questions regarding this change:

1) Should one remove ES2 and ES5 adapters (maven modules) in favor of
single one: just ES ? This will be backwards incompatible change. Or keep
them as is and create a new module ? There is also quite a bit of ES
related code in calcite-core.

2) Since I need to create / parse JSON formats, ES adapter would have to
depend on some JSON library (most likely existing Jackson). Is that
acceptable ?



On Fri, May 18, 2018 at 4:29 PM Andrei Sereda  wrote:


I believe this shouldn't be an issue with http client (contrary to

native

transport)

On Fri, May 18, 2018, 16:16 Christian Beikov <

christian.bei...@gmail.com

wrote:


That's mainly because the Java drivers changed in a way that made
impossible to use the same adapter. I might be wrong, but I think the
ES5 adapter doesn't work with an ES2 server instance just like the ES2
adapter doesn't work with an ES5+ server instance.

If all of this could just go away, that would be great :)


Mit freundlichen Grüßen,




*Christian Beikov*
Am 18.05.2018 um 21:19 schrieb Andrei Sereda:

Yes it should be, since it is just an http client (apache http).
ElasticSearch Rest API (query API) didn't change much
<

https://www.elastic.co/guide/en/elasticsearch/reference/5.0/breaking-changes-5.0.html

.

Next question would be : why there is a need in two separate modules
elasticsearch2 and elasticsearch5

On Fri, May 18, 2018 at 3:11 PM, Christian Beikov <
christian.bei...@gmail.com> wrote:


Hey Andrei,

that would be awesome! Do you know by any chance if the low level

client

is also compatible with older ES versions?


Mit freundlichen Grüßen,




*Christian Beikov*
Am 18.05.2018 um 20:45 schrieb Andrei Sereda:


Hello,

ES TransportClient is deprecated in 7.0 (to be removed

in 8.0) in favor of http rest client(s). Would you consider a

contribution

switching to Rest Low-Level Client
(which
has much fewer dependencies) ?


Thanks,
Andrei.

Re: ElasticSearch use of rest client (instead of TransportClient)

[Andrei Sereda]

1) If we go single (and separate) ES adapter route, people will have to
change their existing maven dependencies as well as ES schema configuration
(at least SchemaFactory name). I'm not sure if there are any explicit (or
implicit) backwards compatibility policies in calcite. There are (albeit)
small implications for end-user.

On Fri, Jun 22, 2018 at 12:54 PM Michael Mior  wrote:

> 1) I personally would be open to this unless there's strong evidence of use
> of the ES2 adapter.
>
> 2) Calcite already depends on Jackson in core and both ES modules, so this
> isn't a concern.
> --
> Michael Mior
> mm...@apache.org
>
>
>
> Le ven. 22 juin 2018 à 12:37, Andrei Sereda  a écrit :
>
> > Some questions regarding this change:
> >
> > 1) Should one remove ES2 and ES5 adapters (maven modules) in favor of
> > single one: just ES ? This will be backwards incompatible change. Or keep
> > them as is and create a new module ? There is also quite a bit of ES
> > related code in calcite-core.
> >
> > 2) Since I need to create / parse JSON formats, ES adapter would have to
> > depend on some JSON library (most likely existing Jackson). Is that
> > acceptable ?
> >
> >
> >
> > On Fri, May 18, 2018 at 4:29 PM Andrei Sereda  wrote:
> >
> > > I believe this shouldn't be an issue with http client (contrary to
> native
> > > transport)
> > >
> > > On Fri, May 18, 2018, 16:16 Christian Beikov <
> christian.bei...@gmail.com
> > >
> > > wrote:
> > >
> > >> That's mainly because the Java drivers changed in a way that made
> > >> impossible to use the same adapter. I might be wrong, but I think the
> > >> ES5 adapter doesn't work with an ES2 server instance just like the ES2
> > >> adapter doesn't work with an ES5+ server instance.
> > >>
> > >> If all of this could just go away, that would be great :)
> > >>
> > >>
> > >> Mit freundlichen Grüßen,
> > >>
> 
> > >> *Christian Beikov*
> > >> Am 18.05.2018 um 21:19 schrieb Andrei Sereda:
> > >> > Yes it should be, since it is just an http client (apache http).
> > >> > ElasticSearch Rest API (query API) didn't change much
> > >> > <
> > >>
> >
> https://www.elastic.co/guide/en/elasticsearch/reference/5.0/breaking-changes-5.0.html
> > >> >
> > >> > .
> > >> >
> > >> > Next question would be : why there is a need in two separate modules
> > >> > elasticsearch2 and elasticsearch5
> > >> >
> > >> > On Fri, May 18, 2018 at 3:11 PM, Christian Beikov <
> > >> > christian.bei...@gmail.com> wrote:
> > >> >
> > >> >> Hey Andrei,
> > >> >>
> > >> >> that would be awesome! Do you know by any chance if the low level
> > >> client
> > >> >> is also compatible with older ES versions?
> > >> >>
> > >> >>
> > >> >> Mit freundlichen Grüßen,
> > >> >>
> > >>
> 
> > >> >> *Christian Beikov*
> > >> >> Am 18.05.2018 um 20:45 schrieb Andrei Sereda:
> > >> >>
> > >> >>> Hello,
> > >> >>>
> > >> >>> ES TransportClient is deprecated in 7.0 (to be removed
> > >> >>>  > >> >>> pi/master/transport-client.html>
> > >> >>> in 8.0) in favor of http rest client(s). Would you consider a
> > >> contribution
> > >> >>> switching to Rest Low-Level Client
> > >> >>>  > >> >>> est/current/java-rest-low.html>(which
> > >> >>> has much fewer dependencies) ?
> > >> >>>
> > >> >>>
> > >> >>> Thanks,
> > >> >>> Andrei.
> > >> >>>
> > >> >>>
> > >>
> > >>
> >
>

Re: ElasticSearch use of rest client (instead of TransportClient)

[Michael Mior]

1) I personally would be open to this unless there's strong evidence of use
of the ES2 adapter.

2) Calcite already depends on Jackson in core and both ES modules, so this
isn't a concern.
--
Michael Mior
mm...@apache.org



Le ven. 22 juin 2018 à 12:37, Andrei Sereda  a écrit :

> Some questions regarding this change:
>
> 1) Should one remove ES2 and ES5 adapters (maven modules) in favor of
> single one: just ES ? This will be backwards incompatible change. Or keep
> them as is and create a new module ? There is also quite a bit of ES
> related code in calcite-core.
>
> 2) Since I need to create / parse JSON formats, ES adapter would have to
> depend on some JSON library (most likely existing Jackson). Is that
> acceptable ?
>
>
>
> On Fri, May 18, 2018 at 4:29 PM Andrei Sereda  wrote:
>
> > I believe this shouldn't be an issue with http client (contrary to native
> > transport)
> >
> > On Fri, May 18, 2018, 16:16 Christian Beikov  >
> > wrote:
> >
> >> That's mainly because the Java drivers changed in a way that made
> >> impossible to use the same adapter. I might be wrong, but I think the
> >> ES5 adapter doesn't work with an ES2 server instance just like the ES2
> >> adapter doesn't work with an ES5+ server instance.
> >>
> >> If all of this could just go away, that would be great :)
> >>
> >>
> >> Mit freundlichen Grüßen,
> >> 
> >> *Christian Beikov*
> >> Am 18.05.2018 um 21:19 schrieb Andrei Sereda:
> >> > Yes it should be, since it is just an http client (apache http).
> >> > ElasticSearch Rest API (query API) didn't change much
> >> > <
> >>
> https://www.elastic.co/guide/en/elasticsearch/reference/5.0/breaking-changes-5.0.html
> >> >
> >> > .
> >> >
> >> > Next question would be : why there is a need in two separate modules
> >> > elasticsearch2 and elasticsearch5
> >> >
> >> > On Fri, May 18, 2018 at 3:11 PM, Christian Beikov <
> >> > christian.bei...@gmail.com> wrote:
> >> >
> >> >> Hey Andrei,
> >> >>
> >> >> that would be awesome! Do you know by any chance if the low level
> >> client
> >> >> is also compatible with older ES versions?
> >> >>
> >> >>
> >> >> Mit freundlichen Grüßen,
> >> >>
> >> 
> >> >> *Christian Beikov*
> >> >> Am 18.05.2018 um 20:45 schrieb Andrei Sereda:
> >> >>
> >> >>> Hello,
> >> >>>
> >> >>> ES TransportClient is deprecated in 7.0 (to be removed
> >> >>>  >> >>> pi/master/transport-client.html>
> >> >>> in 8.0) in favor of http rest client(s). Would you consider a
> >> contribution
> >> >>> switching to Rest Low-Level Client
> >> >>>  >> >>> est/current/java-rest-low.html>(which
> >> >>> has much fewer dependencies) ?
> >> >>>
> >> >>>
> >> >>> Thanks,
> >> >>> Andrei.
> >> >>>
> >> >>>
> >>
> >>
>

Re: ElasticSearch use of rest client (instead of TransportClient)

[Andrei Sereda]

Some questions regarding this change:

1) Should one remove ES2 and ES5 adapters (maven modules) in favor of
single one: just ES ? This will be backwards incompatible change. Or keep
them as is and create a new module ? There is also quite a bit of ES
related code in calcite-core.

2) Since I need to create / parse JSON formats, ES adapter would have to
depend on some JSON library (most likely existing Jackson). Is that
acceptable ?



On Fri, May 18, 2018 at 4:29 PM Andrei Sereda  wrote:

> I believe this shouldn't be an issue with http client (contrary to native
> transport)
>
> On Fri, May 18, 2018, 16:16 Christian Beikov 
> wrote:
>
>> That's mainly because the Java drivers changed in a way that made
>> impossible to use the same adapter. I might be wrong, but I think the
>> ES5 adapter doesn't work with an ES2 server instance just like the ES2
>> adapter doesn't work with an ES5+ server instance.
>>
>> If all of this could just go away, that would be great :)
>>
>>
>> Mit freundlichen Grüßen,
>> 
>> *Christian Beikov*
>> Am 18.05.2018 um 21:19 schrieb Andrei Sereda:
>> > Yes it should be, since it is just an http client (apache http).
>> > ElasticSearch Rest API (query API) didn't change much
>> > <
>> https://www.elastic.co/guide/en/elasticsearch/reference/5.0/breaking-changes-5.0.html
>> >
>> > .
>> >
>> > Next question would be : why there is a need in two separate modules
>> > elasticsearch2 and elasticsearch5
>> >
>> > On Fri, May 18, 2018 at 3:11 PM, Christian Beikov <
>> > christian.bei...@gmail.com> wrote:
>> >
>> >> Hey Andrei,
>> >>
>> >> that would be awesome! Do you know by any chance if the low level
>> client
>> >> is also compatible with older ES versions?
>> >>
>> >>
>> >> Mit freundlichen Grüßen,
>> >>
>> 
>> >> *Christian Beikov*
>> >> Am 18.05.2018 um 20:45 schrieb Andrei Sereda:
>> >>
>> >>> Hello,
>> >>>
>> >>> ES TransportClient is deprecated in 7.0 (to be removed
>> >>> > >>> pi/master/transport-client.html>
>> >>> in 8.0) in favor of http rest client(s). Would you consider a
>> contribution
>> >>> switching to Rest Low-Level Client
>> >>> > >>> est/current/java-rest-low.html>(which
>> >>> has much fewer dependencies) ?
>> >>>
>> >>>
>> >>> Thanks,
>> >>> Andrei.
>> >>>
>> >>>
>>
>>

Re: Creating filter expressions with java predicates

[Stamatis Zampetakis]

Hi Julian,

Thanks a lot for the suggestions.

Unfortunately, the API (public and quite old) for defining the predicates
is quite permissive and it does not impose anything regarding a public
no-arg constructor or stateless behavior.

I don't think a TableFunctionScan is a good fit for the use-case I
described. Maybe it was not clear from my previous example but the
predicate takes as an input a single row of the input relational expression
and either lets it pass or not.
I see how the TableFunctionScan could work but the semantics of this
expression are quite different than those of a Filter (most importantly the
fact that it cannot introduce new rows or change the type of the input
expression).

Continuing on the idea of using a user-defined function, I would say that
one argument is the type of the table (record type?) and the output is a
boolean, and this brings me to another question.

*How can we describe with a row expression (RexNode) that the input to a
function is the complete row from the input relational expression?*

For the sake of the example, let's assume that we have a Scan over the
following table: EMP(EMPNO, ENAME, DEPTNO). Furthermore, we want to apply a
Filter with a function similar to the one below:
boolean isValidEmployee(Object[] emp)

If I had to create such an expression manually, I think it would be
something with the following structure:

RexCall(RexCall(RexInputRef,RexInputRef,RexInputRef)) =>
ISVALIDEMPLOYEE(ROW($0,
$1, $2))

or

RexCall(RexCall(RexLiteral)) => ISVALIDEMPLOYEE(RINPUT(0))

Is there a Calcite convention on how to treat this situation (possibly test
cases which exhibit such use-cases)?

Best,
Stamatis

2018-06-22 2:54 GMT+02:00 Julian Hyde :

> Regardless of how you create it, it’s difficult to pass arbitrary objects
> into a plan. It you can ensure that each predicate has a public
> no-arguments constructor, you could pass the predicate’s class name. Then
> your custom operator can instantiate the predicate.


> One option is to create a user-defined table function. One of its
> arguments will be a cursor (the input relational expression) and other
> arguments will be the names of the predicate classes. Its output is a
> cursor.
>
> There is currently no method in RelBuilder to add a table function scan
> (see https://issues.apache.org/jira/browse/CALCITE-1515 <
> https://issues.apache.org/jira/browse/CALCITE-1515>) but you can create
> one manually:
>
>   RelBuilder relBuilder;
>   …
>   List inputs = ImmutableList.of(relBuilder.build());
>   relBuilder.push(new TableFunctionScan(…, inputs, …));
>
> Because of RelBuilder’s stack model, you can easily mix RelNodes that it
> creates with RelNodes you create manually.
>
> Julian
>
>
> > On Jun 21, 2018, at 2:06 AM, Stamatis Zampetakis 
> wrote:
> >
> > Hi all,
> >
> > I am trying to replace pieces of an old query execution framework with
> > Calcite. Consider for example the following very simplified
> representation
> > of such Query in this framework.
> >
> > class Query
> > {
> > private final String pathToTableData;
> > private final Predicate pred1;
> > private final Predicate pred2;
> > }
> >
> > Basically, it corresponds to a TableScan with Filter(s) so I would like
> to
> > map it as such to Calcite.
> >
> > *Approach A*
> > The first thing that came to my mind is to use the RelBuilder and
> > RexBuilder classes to do so. Then when I am about to create a filter, I
> am
> > not sure how to create the respective row expression that is able to
> > describe the above predicates. At the moment, I have the following ideas:
> >
> >   1. One possibility would be to create RexCall expression with a custom
> >   SqlOperator that takes the java predicate among its parameters.
> >   2. Another possibility would be to create RexCall expression with a
> >   SqlUserDefinedFunction that already accepts as an input a Function
> object
> >   and there I could pass a custom Function object that contains the java
> >   Predicate.
> >
> > Then during query planning, it is necessary to add an appropriate rule
> that
> > goes over the condition of the filter examine the SqlOperator and
> introduce
> > a CustomFilter expression for handling this call.
> >
> > *Approach B*
> > The second alternative would be to not to use at all the RelBuilder and
> > build the plan manually with custom relational expressions (subclasses of
> > RelNode). As such the CustomFilter expression could take as an argument a
> > java predicate and there is no need to introduce further changes or
> rules.
> > The latter implies that the CustomFilter does not have a RexNode
> condition,
> > which further means that it cannot inherit from the existing Filter
> class.
> >
> > I was wondering if any of the above approaches seems reasonable enough
> and
> > if there are other better alternatives that I am missing. Suggestions and
> > comments are very welcomed.
>
>