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

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)

Calcite-Master - Build # 310 - Still Failing

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.

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

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

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

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 >

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

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

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

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

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

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

Re: [2/2] calcite git commit: [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of ES adapter (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

Re: [2/2] calcite git commit: [CALCITE-2347] running ElasticSearch in embedded mode for unit tests of ES adapter (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

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

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 -

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

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 -

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

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”

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

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

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

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

Calcite-Master - Build # 309 - Still Failing

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: ElasticSearch use of rest client (instead of TransportClient)

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

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

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

Re: Gandiva

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

Re: Gandiva

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

Gandiva

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,

Re: Creating filter expressions with java predicates

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