[jira] [Updated] (CALCITE-2380) Elasticsearch, MongoDB, Druid adapters have javadoc errors
[
https://issues.apache.org/jira/browse/CALCITE-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2380:
-
Component/s: mongodb
elasticsearch-adapter
> Elasticsearch, MongoDB, Druid adapters have javadoc errors
> --
>
> Key: CALCITE-2380
> URL: https://issues.apache.org/jira/browse/CALCITE-2380
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter, mongodb
>Reporter: Andrei Sereda
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> javadoc generation fails for some adapters.
> Commands to reproduce:
> {code:java}
> $ mvn -DskipTests clean javadoc:javadoc javadoc:test-javadoc
> $ mvn -DskipTests clean site{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2380) Elasticsearch, MongoDB, Druid adapters have javadoc errors
[
https://issues.apache.org/jira/browse/CALCITE-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523242#comment-16523242
]
Julian Hyde commented on CALCITE-2380:
--
The fatal javadoc error, caused by the fact that elasticsearch5 and
elasticsearch2 namespaces overlap, is fixed in
[9721283bd|http://git-wip-us.apache.org/repos/asf/calcite/commit/9721283bd];
warnings fixed in
[4f835465|http://git-wip-us.apache.org/repos/asf/calcite/commit/4f835465].
Thanks for the fix, [~asereda]!
In [6e8bb5a16|http://git-wip-us.apache.org/repos/asf/calcite/commit/6e8bb5a16],
I renamed "Elastic" and "ElasticSearch" classes to "Elasticsearch" for
consistency, and applied standard indentation (2 + 4) to all code.
> Elasticsearch, MongoDB, Druid adapters have javadoc errors
> --
>
> Key: CALCITE-2380
> URL: https://issues.apache.org/jira/browse/CALCITE-2380
> Project: Calcite
> Issue Type: Bug
>Reporter: Andrei Sereda
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> javadoc generation fails for some adapters.
> Commands to reproduce:
> {code:java}
> $ mvn -DskipTests clean javadoc:javadoc javadoc:test-javadoc
> $ mvn -DskipTests clean site{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2380) Elasticsearch, MongoDB, Druid adapters have javadoc errors
[
https://issues.apache.org/jira/browse/CALCITE-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-2380.
--
Resolution: Fixed
Fix Version/s: 1.17.0
> Elasticsearch, MongoDB, Druid adapters have javadoc errors
> --
>
> Key: CALCITE-2380
> URL: https://issues.apache.org/jira/browse/CALCITE-2380
> Project: Calcite
> Issue Type: Bug
>Reporter: Andrei Sereda
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> javadoc generation fails for some adapters.
> Commands to reproduce:
> {code:java}
> $ mvn -DskipTests clean javadoc:javadoc javadoc:test-javadoc
> $ mvn -DskipTests clean site{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2380) Elasticsearch, MongoDB, Druid adapters have javadoc errors
[
https://issues.apache.org/jira/browse/CALCITE-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2380:
-
Summary: Elasticsearch, MongoDB, Druid adapters have javadoc errors (was:
javadoc failures for some adapters)
> Elasticsearch, MongoDB, Druid adapters have javadoc errors
> --
>
> Key: CALCITE-2380
> URL: https://issues.apache.org/jira/browse/CALCITE-2380
> Project: Calcite
> Issue Type: Bug
>Reporter: Andrei Sereda
>Assignee: Julian Hyde
>Priority: Major
>
> javadoc generation fails for some adapters.
> Commands to reproduce:
> {code:java}
> $ mvn -DskipTests clean javadoc:javadoc javadoc:test-javadoc
> $ mvn -DskipTests clean site{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2335) Switch to vgo for dependency management
[ https://issues.apache.org/jira/browse/CALCITE-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-2335: Fix Version/s: avatica-go-3.1.0 > Switch to vgo for dependency management > --- > > Key: CALCITE-2335 > URL: https://issues.apache.org/jira/browse/CALCITE-2335 > Project: Calcite > Issue Type: Task > Components: avatica-go >Reporter: Francis Chuang >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-go-3.1.0 > > > The proposal for vgo has been accepted: > [https://research.swtch.com/vgo-accepted] > vgo aims to replace dep for dependency management in Go. > TLDR; vgo will be part of the Go tool chain in Go 1.11 (July 31 2018) on an > experimental basis. Official production-ready status will be in Go 1.12 > (January 2019). > We should remove dep and move to vgo when Go 1.11 is released so that we can > work out any idiosyncrasies before Go 1.12. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2379) CVSS dependency-check-maven fails for calcite-spark module
[
https://issues.apache.org/jira/browse/CALCITE-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-2379:
Component/s: spark
> CVSS dependency-check-maven fails for calcite-spark module
> --
>
> Key: CALCITE-2379
> URL: https://issues.apache.org/jira/browse/CALCITE-2379
> Project: Calcite
> Issue Type: Bug
> Components: spark
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Check for vulnerabilities among dependencies fails for {{calcite-spark}}
> module.
> Output for "{{mvn install -Ppedantic -DskipTests=true}}":
> {noformat}
> One or more dependencies were identified with known vulnerabilities in
> Calcite Spark:
> jackson-databind-2.9.4.jar
> (com.fasterxml.jackson.core:jackson-databind:2.9.4,
> cpe:/a:fasterxml:jackson-databind:2.9.4, cpe:/a:fasterxml:jackson:2.9.4) :
> CVE-2018-7489
> protobuf-java-3.3.0.jar (com.google.protobuf:protobuf-java:3.3.0,
> cpe:/a:google:protobuf:3.3.0) : CVE-2015-5237
> commons-beanutils-core-1.8.0.jar
> (commons-beanutils:commons-beanutils-core:1.8.0,
> cpe:/a:apache:commons_beanutils:1.8.0) : CVE-2014-0114
> commons-beanutils-1.7.0.jar (commons-beanutils:commons-beanutils:1.7.0,
> cpe:/a:apache:commons_beanutils:1.7.0) : CVE-2014-0114
> commons-httpclient-3.1.jar (commons-httpclient:commons-httpclient:3.1,
> cpe:/a:apache:commons-httpclient:3.1, cpe:/a:apache:httpclient:3.1) :
> CVE-2015-5262, CVE-2014-3577
> javax.annotation-api-1.2.jar (cpe:/a:oracle:glassfish:1.2,
> javax.annotation:javax.annotation-api:1.2) : CVE-2015-2808, CVE-2013-2566
> mail-1.4.7.jar (cpe:/a:mail_project:mail:1.4.7, javax.mail:mail:1.4.7) :
> CVE-2015-9097
> validation-api-1.1.0.Final.jar
> (cpe:/a:bean_project:bean:7.x-1.1::~~~drupal~~,
> javax.validation:validation-api:1.1.0.Final) : CVE-2013-4499
> jaxb-api-2.2.2.jar (cpe:/a:fish:fish:2.2.2, cpe:/a:oracle:glassfish:2.2.2,
> javax.xml.bind:jaxb-api:2.2.2) : CVE-2015-2808, CVE-2013-2566
> pyrolite-4.13.jar (cpe:/a:pickle:pickle:4.13, net.razorvine:pyrolite:4.13) :
> CVE-2007-1100
> py4j-0.10.4.jar (cpe:/a:python:python:0.10.4,
> cpe:/a:python_software_foundation:python:0.10.4, net.sf.py4j:py4j:0.10.4) :
> CVE-2018-130, CVE-2017-18207, CVE-2017-17522, CVE-2017-1000158,
> CVE-2016-5699, CVE-2016-5636, CVE-2016-1494, CVE-2016-0772, CVE-2015-5652,
> CVE-2014-7185, CVE-2014-3539, CVE-2013-7440, CVE-2013-7338, CVE-2012-1150,
> CVE-2012-0845, CVE-2011-4940, CVE-2010-3492, CVE-2008-5983, CVE-2008-3143,
> CVE-2008-3142, CVE-2008-2315, CVE-2008-1887, CVE-2008-1721, CVE-2008-1679,
> CVE-2007-4559, CVE-2006-1542, CVE-2002-1119
> avro-mapred-1.7.7-hadoop2.jar (cpe:/a:apache:hadoop:1.7.7,
> org.apache.avro:avro-mapred:1.7.7) : CVE-2017-3162, CVE-2017-3161,
> CVE-2016-5001
> curator-recipes-2.6.0.jar (cpe:/a:apache:zookeeper:2.6.0,
> org.apache.curator:curator-recipes:2.6.0) : CVE-2016-5017, CVE-2014-0085
> api-util-1.0.0-M20.jar (cpe:/a:apache:directory_ldap_api:1.0.0.m30,
> org.apache.directory.api:api-util:1.0.0-M20) : CVE-2015-3250
> xbean-asm5-shaded-4.4.jar (cpe:/a:apache:geronimo:4.4) : CVE-2008-0732
> zookeeper-3.4.6.jar (cpe:/a:apache:zookeeper:3.4.6,
> org.apache.zookeeper:zookeeper:3.4.6) : CVE-2017-5637, CVE-2016-5017,
> CVE-2014-0085
> jackson-xc-1.9.13.jar (cpe:/a:fasterxml:jackson-databind:1.9.13,
> cpe:/a:fasterxml:jackson:1.9.13, org.codehaus.jackson:jackson-xc:1.9.13) :
> CVE-2018-5968, CVE-2017-17485
> jetty-http-9.2.19.v20160908.jar (cpe:/a:eclipse:jetty:9.2.19.v20160908,
> cpe:/a:jetty:jetty:9.2.19.v20160908,
> org.eclipse.jetty:jetty-http:9.2.19.v20160908) : CVE-2017-9735
> jetty-util-6.1.26.jar (cpe:/a:jetty:jetty:6.1.26,
> cpe:/a:mortbay:jetty:6.1.26, cpe:/a:mortbay_jetty:jetty:6.1.26,
> org.mortbay.jetty:jetty-util:6.1.26) : CVE-2011-4461
> unused-1.0.0.jar (cpe:/a:apache:spark:1.0.0,
> org.spark-project.spark:unused:1.0.0) : CVE-2017-7678
> xz-1.0.jar (cpe:/a:tukaani:xz:1.0, org.tukaani:xz:1.0) : CVE-2015-4035
> serializer-2.7.1.jar (cpe:/a:apache:xalan-java:2.7.1, xalan:serializer:2.7.1)
> : CVE-2014-0107
> xalan-2.7.1.jar (cpe:/a:apache:xalan-java:2.7.1, xalan:xalan:2.7.1) :
> CVE-2014-0107
> xercesImpl-2.9.1.jar (cpe:/a:apache:xerces2_java:2.9.1,
> xerces:xercesImpl:2.9.1) : CVE-2012-0881
> htrace-core-3.1.0-incubating.jar/META-INF/maven/com.fasterxml.jackson.core/jackson-databind/pom.xml
> (com.fasterxml.jackson.core:jackson-databind:2.4.0,
> cpe:/a:fasterxml:jackson-databind:2.4.0, cpe:/a:fasterxml:jackson:2.4.0) :
> CVE-2018-7489, CVE-2018-5968, CVE-2017-7525, CVE-2017-17485, CVE-2017-15095
> spark-core_2.10-2.2.0.jar/META-INF/maven/org.eclipse.jetty/jetty-plus/pom.xml
> (cpe:/a:eclipse:jetty:9.3.11.v20160721, cpe:/a:jetty:jetty:9.3.11.v20160721,
>
[jira] [Updated] (CALCITE-2299) TIMESTAMPADD(SQL_TSI_FRAC_SECOND) should be nanoseconds not microseconds
[ https://issues.apache.org/jira/browse/CALCITE-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-2299: Fix Version/s: (was: avatica-1.12.0) avatica-1.13.0 > TIMESTAMPADD(SQL_TSI_FRAC_SECOND) should be nanoseconds not microseconds > > > Key: CALCITE-2299 > URL: https://issues.apache.org/jira/browse/CALCITE-2299 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.16.0 >Reporter: James Duong >Assignee: Julian Hyde >Priority: Minor > Fix For: avatica-1.13.0 > > > When calling TIMESTAMPADD with the first parameter SQL_TSI_FRAC_SECOND and > the JDBC escape sequence, this gets interpreted as microseconds when it > should be interpreted as nanoseconds. > > From the ODBC spec on MSDN: > [https://docs.microsoft.com/en-us/sql/odbc/reference/appendixes/time-date-and-interval-functions?view=sql-server-2017] > 'where fractional seconds are expressed in billionths of a second.' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1385) Support password-based convenience logins for Kerberos-authenticated clients
[ https://issues.apache.org/jira/browse/CALCITE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-1385: Fix Version/s: (was: avatica-1.12.0) avatica-1.13.0 > Support password-based convenience logins for Kerberos-authenticated clients > > > Key: CALCITE-1385 > URL: https://issues.apache.org/jira/browse/CALCITE-1385 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.13.0 > > > Had a request for the automatic Kerberos login process to also support > password-based authentication (instead of just keytab). > This would require some extra logic in KerberosConnection to do the Jaas > Configuration with the provided password, but not attempt to prompt the user > for it (as it might be a headless client, like some GUI application). > One problem is that GUI apps will likely try to use pass this value in via > the "password" key in some properties (in addition to the "user" field). Will > actually have to try to test this out to make sure it works as intended. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1183) Sporadic AvaticaSpnegoTest failures with Checksum failed and HTTP 404
[
https://issues.apache.org/jira/browse/CALCITE-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-1183:
Fix Version/s: (was: avatica-1.12.0)
avatica-1.13.0
> Sporadic AvaticaSpnegoTest failures with Checksum failed and HTTP 404
> -
>
> Key: CALCITE-1183
> URL: https://issues.apache.org/jira/browse/CALCITE-1183
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Priority: Minor
> Fix For: avatica-1.13.0
>
>
> I'm noticing the following every now and again.
> {noformat}
> 2016-04-04 10:59:29,110 [main] INFO - Starting KDC server at localhost:62139
> 2016-04-04 10:59:29,281 [main] INFO - Creating client with keytab
> /Users/jelser/projects/calcite.git/avatica/server/target/AvaticaSpnegoTest_keytabs/client.keytab
> 2016-04-04 10:59:29,286 [main] INFO - Creating HTTP/localh...@example.com
> with keytab
> /Users/jelser/projects/calcite.git/avatica/server/target/AvaticaSpnegoTest_keytabs/HTTP_localhost.keytab
> 2016-04-04 10:59:29,368 [main] INFO - No metrics implementation available on
> classpath. Using No-op implementation
> 2016-04-04 10:59:29,385 [main] INFO - Logging initialized @618ms
> java.net.SocketTimeoutException: Accept timed out
> java.net.SocketTimeoutException: Accept timed out
> java.net.SocketTimeoutException: Accept timed out
> 2016-04-04 10:59:29,649 [main] INFO - jetty-9.2.15.v20160210
> 2016-04-04 10:59:29,682 [main] INFO - Started
> ServerConnector@11fa682c{HTTP/1.1}{0.0.0.0:62141}
> 2016-04-04 10:59:29,682 [main] INFO - Started @916ms
> 2016-04-04 10:59:29,682 [main] INFO - Service listening on port 62141.
> 2016-04-04 10:59:29,685 [main] INFO - JDBC URL
> jdbc:avatica:remote:url=http://localhost:62141;authentication=SPNEGO;serialization=JSON
> 2016-04-04 10:59:29,686 [main] INFO - No metrics implementation available on
> classpath. Using No-op implementation
> java.net.SocketTimeoutException: Accept timed out
> 2016-04-04 10:59:29,759 [main] INFO - jetty-9.2.15.v20160210
> 2016-04-04 10:59:29,772 [main] INFO - Started
> ServerConnector@5c80435f{HTTP/1.1}{0.0.0.0:62142}
> 2016-04-04 10:59:29,772 [main] INFO - Started @1006ms
> 2016-04-04 10:59:29,772 [main] INFO - Service listening on port 62142.
> 2016-04-04 10:59:29,772 [main] INFO - JDBC URL
> jdbc:avatica:remote:url=http://localhost:62142;authentication=SPNEGO;serialization=PROTOBUF
> 2016-04-04 10:59:29,787 [main] INFO - jetty-9.2.15.v20160210
> 2016-04-04 10:59:29,789 [main] INFO - Started
> ServerConnector@464d02ee{HTTP/1.1}{0.0.0.0:62143}
> 2016-04-04 10:59:29,789 [main] INFO - Started @1023ms
> 2016-04-04 10:59:29,789 [main] INFO - Service listening on port 62143.
> 2016-04-04 10:59:29,790 [main] INFO - jetty-9.2.15.v20160210
> 2016-04-04 10:59:29,791 [main] INFO - Started
> ServerConnector@3ff9f777{HTTP/1.1}{0.0.0.0:62144}
> 2016-04-04 10:59:29,792 [main] INFO - Started @1026ms
> 2016-04-04 10:59:29,792 [main] INFO - Service listening on port 62144.
> java.net.SocketTimeoutException: Accept timed out
> Running org.apache.calcite.avatica.AvaticaSpnegoTest
> 2016-04-04 10:59:29,837 [main] INFO - Starting KDC server at localhost:62146
> 2016-04-04 10:59:29,841 [main] INFO - Creating client with keytab
> /Users/jelser/projects/calcite.git/avatica/server/target/AvaticaSpnegoTest_keytabs/client.keytab
> 2016-04-04 10:59:29,842 [main] INFO - Creating HTTP/localh...@example.com
> with keytab
> /Users/jelser/projects/calcite.git/avatica/server/target/AvaticaSpnegoTest_keytabs/HTTP_localhost.keytab
> 2016-04-04 10:59:29,845 [main] INFO - No metrics implementation available on
> classpath. Using No-op implementation
> 2016-04-04 10:59:29,846 [main] INFO - jetty-9.2.15.v20160210
> 2016-04-04 10:59:29,847 [main] INFO - Started
> ServerConnector@4cf35c4f{HTTP/1.1}{0.0.0.0:62148}
> 2016-04-04 10:59:29,848 [main] INFO - Started @1082ms
> 2016-04-04 10:59:29,848 [main] INFO - Service listening on port 62148.
> 2016-04-04 10:59:29,848 [main] INFO - JDBC URL
> jdbc:avatica:remote:url=http://localhost:62148;authentication=SPNEGO;serialization=JSON
> 2016-04-04 10:59:29,848 [main] INFO - No metrics implementation available on
> classpath. Using No-op implementation
> 2016-04-04 10:59:29,849 [main] INFO - jetty-9.2.15.v20160210
> 2016-04-04 10:59:29,851 [main] INFO - Started
> ServerConnector@4be0b391{HTTP/1.1}{0.0.0.0:62149}
> 2016-04-04 10:59:29,851 [main] INFO - Started @1085ms
> 2016-04-04 10:59:29,851 [main] INFO - Service listening on port 62149.
> 2016-04-04 10:59:29,851 [main] INFO - JDBC URL
> jdbc:avatica:remote:url=http://localhost:62149;authentication=SPNEGO;serialization=PROTOBUF
> Debug is true storeKey true useTicketCache false useKeyTab true doNotPrompt
>
[jira] [Updated] (CALCITE-2255) Test against JDK 11
[ https://issues.apache.org/jira/browse/CALCITE-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-2255: Fix Version/s: (was: avatica-1.12.0) avatica-1.13.0 > Test against JDK 11 > --- > > Key: CALCITE-2255 > URL: https://issues.apache.org/jira/browse/CALCITE-2255 > Project: Calcite > Issue Type: Improvement >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Major > Fix For: 1.17.0, avatica-1.13.0 > > > JDK 11 ([http://jdk.java.net/11/)] is in early release and we can start > testing against it. With the improvements from CALCITE-2063, we should be > able to test against JDK 11 without much effort. > I opened [https://github.com/docker-library/openjdk/pull/186] and > [https://github.com/carlossg/docker-maven/issues/79] to try to get JDK 11 > support for the docker images we are trying to use. > I am working on testing locally as well to see if there is anything broken. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2303) Support DECADE time unit in EXTRACT function
[
https://issues.apache.org/jira/browse/CALCITE-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-2303:
Fix Version/s: (was: avatica-1.12.0)
avatica-1.13.0
> Support DECADE time unit in EXTRACT function
>
>
> Key: CALCITE-2303
> URL: https://issues.apache.org/jira/browse/CALCITE-2303
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0, avatica-1.13.0
>
>
> Here CALCITE-1177 were supported new units
> however such test
> {code:java}
> @Test public void testDecadeFunction() throws Exception {
> ExpressionChecker checker = new ExpressionChecker()
> .addExpr("EXTRACT(DECADE FROM ts)", 199L)
> ;
> checker.buildRunAndCheck();
> }
> {code}
> failed like
> Extract for time unit: DECADE not supported!
> {noformat}
> SQL:>
> SELECT EXTRACT(DECADE FROM ts) FROM PCOLLECTION
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> validateAndConvert
> INFO: SQL:
> SELECT EXTRACT(DECADE FROM `PCOLLECTION`.`ts`)
> FROM `PCOLLECTION` AS `PCOLLECTION`
> May 08, 2018 1:34:58 PM
> org.apache.beam.sdk.extensions.sql.impl.planner.BeamQueryPlanner
> convertToBeamRel
> INFO: SQLPlan>
> LogicalProject(EXPR$0=[EXTRACT(FLAG(DECADE), $0)])
> BeamIOSourceRel(table=[[PCOLLECTION]])
> java.lang.RuntimeException:
> org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlBuiltinFunctionsIntegrationTestBase$ExpressionChecker.buildRunAndCheck(BeamSqlBuiltinFunctionsIntegrationTestBase.java:167)
> at
> org.apache.beam.sdk.extensions.sql.integrationtest.BeamSqlDateFunctionsIntegrationTest.testDecadeFunction(BeamSqlDateFunctionsIntegrationTest.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.beam.sdk.testing.TestPipeline$1.evaluate(TestPipeline.java:317)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.beam.sdk.Pipeline$PipelineExecutionException:
> java.lang.UnsupportedOperationException: Extract for time unit: DECADE not
> supported!
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:349)
> at
> org.apache.beam.runners.direct.DirectRunner$DirectPipelineResult.waitUntilFinish(DirectRunner.java:319)
> at
> org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:210)
> at org.apache.beam.runners.direct.DirectRunner.run(DirectRunner.java:66)
> at org.apache.beam.sdk.Pipeline.run(Pipeline.java:311)
> at org.apache.beam.sdk.testing.TestPipeline.run(TestPipeline.java:346)
> at
[jira] [Updated] (CALCITE-839) Remove Jackson annotations from POJO classes in Meta
[ https://issues.apache.org/jira/browse/CALCITE-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-839: --- Fix Version/s: (was: avatica-1.12.0) avatica-1.13.0 > Remove Jackson annotations from POJO classes in Meta > > > Key: CALCITE-839 > URL: https://issues.apache.org/jira/browse/CALCITE-839 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.13.0 > > > The Meta interface contains several POJO classes that represent RPC requests > or responses. Currently a few of those classes have Jackson annotations such > as @JsonCreator, @JsonProperty to help Jackson serialize the POJO to JSON and > de-serialize from JSON to the object. > As [~ndimiduk] pointed out in > http://mail-archives.apache.org/mod_mbox/calcite-dev/201503.mbox/%3CCANZa=gvkgd+bkj4+ejmuo6ivhs+okgskg1vwdazcy-zijyy...@mail.gmail.com%3E > these annotations are a "code smell" and should be removed. It makes it look > as if Jackson is the only possible transport, which is not the case. We can > continue to use Jackson as a transport, just specify the mappings elsewhere, > not as annotations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1157) Automatically activate apache-release profile in release-plugin
[
https://issues.apache.org/jira/browse/CALCITE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-1157:
Fix Version/s: (was: avatica-1.12.0)
avatica-1.13.0
> Automatically activate apache-release profile in release-plugin
> ---
>
> Key: CALCITE-1157
> URL: https://issues.apache.org/jira/browse/CALCITE-1157
> Project: Calcite
> Issue Type: Improvement
> Components: avatica, build
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: avatica-1.13.0
>
>
> Another nice-to-have when making releases:
> {noformat}
>
> org.apache.maven.plugins
> maven-release-plugin
>
> apache-release
>
>
> {noformat}
> Something like the above should automatically enable the apache-release
> plugin (and avoid the case where the developer forgets to enable the profile
> on the commandline).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-1006) Enable spotbugs-maven-plugin
[ https://issues.apache.org/jira/browse/CALCITE-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-1006: Fix Version/s: (was: avatica-1.12.0) avatica-1.13.0 > Enable spotbugs-maven-plugin > > > Key: CALCITE-1006 > URL: https://issues.apache.org/jira/browse/CALCITE-1006 > Project: Calcite > Issue Type: Task > Components: build >Reporter: Josh Elser >Assignee: Kevin Risden >Priority: Major > Fix For: avatica-1.13.0 > > > We can fairly trivially wire up the spotbugs-maven-plugin to get some > static-analysis at build time. This is my tool of choice for the matter – > I'll make sure we have some sane configuration and try to knock out any > issues that it reports. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1308) Implement remaining DatabaseMetaData operations in RemoteMeta
[ https://issues.apache.org/jira/browse/CALCITE-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-1308: Fix Version/s: (was: avatica-1.12.0) avatica-1.13.0 > Implement remaining DatabaseMetaData operations in RemoteMeta > - > > Key: CALCITE-1308 > URL: https://issues.apache.org/jira/browse/CALCITE-1308 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: avatica-1.13.0 > > > Noticed in CALCITE-1291: sqlline normally highlights the column(s) which are > (part of the) primary key. Running a debugger over it quickly, showed that no > keys were returned over the DatabaseMetaData.getPrimaryKeys call. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1242) Allow configuration of maximum allowed value for maxRowCount
[ https://issues.apache.org/jira/browse/CALCITE-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-1242: Fix Version/s: (was: avatica-1.12.0) avatica-1.13.0 > Allow configuration of maximum allowed value for maxRowCount > > > Key: CALCITE-1242 > URL: https://issues.apache.org/jira/browse/CALCITE-1242 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Duo Xu >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.13.0 > > > There are several APIs having the maxRowCount parameter. Currently this > setting is hard coded in Avatica as 100. So if the user set maxRowCount > 100 > in PrepareAndExecuteRequest, for example, the server will still only return > 100 results. So the APIs are currently broken. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1318) Build/Document Avatica Kerberos/SPNEGO authentication behind load balancer.
[ https://issues.apache.org/jira/browse/CALCITE-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-1318: Fix Version/s: (was: avatica-1.12.0) avatica-1.13.0 > Build/Document Avatica Kerberos/SPNEGO authentication behind load balancer. > --- > > Key: CALCITE-1318 > URL: https://issues.apache.org/jira/browse/CALCITE-1318 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.13.0 > > > I was talking with [~_alexm] this weekend about some work that he had > recently done in getting Apache Impala set up behind a load balancer. When > Kerberos is in the picture, he told me that the way that works is that the > impalad daemons actually have two Kerberos identities: one for the hostname > that the impalad service is actually running on and another for the load > balancer host. The load-balancer continues to just do a simple pass-through. > Right now, the Avatica server can only accept a single Kerberos > principal+keytab. This means that we can't use the Kerberos authentication > when the client can access the server via multiple hostnames -- invalidating > the use of 'dumb' load balancers (hypothetically, a smart loadbalancer could > make it work). We could configure the Avatica server to use a principal with > the load-balancer's hostname, but then users would be unable to connect > directly to the server. > I know that Impala uses (or at least exposes) Thrift which has its own SASL > implementation; maybe they do something tricky there? Maybe we can glean > something from their implementation (even though it's not HTTP based). I > don't think JAAS lets us have multiple active logins, so I'm not even sure > where to begin. > Ideally, this is something that would be great to understand and provide some > deployment guidance for users to have identical deployment scenario for > "secure" and "unsecure" scenarios. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1352) Clarify documentation for avatica's max_rows_total
[
https://issues.apache.org/jira/browse/CALCITE-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-1352:
Fix Version/s: (was: avatica-1.12.0)
avatica-1.13.0
> Clarify documentation for avatica's max_rows_total
> --
>
> Key: CALCITE-1352
> URL: https://issues.apache.org/jira/browse/CALCITE-1352
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Affects Versions: avatica-1.8.0
>Reporter: Francis Chuang
>Priority: Minor
> Fix For: avatica-1.13.0
>
>
> The {{max_rows_total}} parameter in the protocol buffer definitions should be
> updated to include more information on values that result in unlimited rows
> being returned.
> When testing against calcite 1.8.0, I observed the following:
> {code}
> -1: Unlimited number of rows
> 0: 0 rows
> 1: 1 row
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-1164) Use setObject(int, Object, int) when binding parameters
[
https://issues.apache.org/jira/browse/CALCITE-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-1164:
Fix Version/s: (was: avatica-1.12.0)
avatica-1.13.0
> Use setObject(int, Object, int) when binding parameters
> ---
>
> Key: CALCITE-1164
> URL: https://issues.apache.org/jira/browse/CALCITE-1164
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Josh Elser
>Priority: Minor
> Fix For: avatica-1.13.0
>
>
> Trying to capture some discussion from a recent pull request:
> https://github.com/apache/calcite/pull/209#issuecomment-195025402
> In a few places (such as
> https://github.com/apache/calcite/blob/master/avatica/server/src/main/java/org/apache/calcite/avatica/jdbc/JdbcMeta.java#L795-L800),
> we perform:
> {code}
> TypedValue o = parameterValues.get(i);
> preparedStatement.setObject(i + 1, o.toJdbc(calendar));
> {code}
> Vladimir stated that this is ambiguous (stored procedures differing by
> argument list and differentiating between the actual type when the value is
> null) and would be remedied by passing along the desired type when setting
> the object.
> We may also have to invoke setNull explicitly? This is unclear to me.
> h5. Reasons why "explicit sql type" is important
> h6. Calling the proper function
> Consider database has two functions that differ in type of argument only.
> For instance {{compute(varchar)}}, {{compute(numeric)}}, and
> {{compute(user_defined_struct)}}
> Which one should be executed if calling with just
> {{preparedStatement.setObject(i, null)}}?
> There is not enough information for the database to choose between varchar
> and numeric function.
> h6. Performance
> Execution plan depends on the types of bind parameters. For instance, in
> PostgreSQL, you must tell all the datatypes of the bind variables right in
> {{PREPARE}} message.
> That basically means, if you flip between datatypes, you have to use
> different prepared statement IDs.
> If just {{String val = ...; ps.setObject(1, val)}} is used, then for non-null
> it can result in {{String}} execution plan, while for null it can flip to
> unknown.
> Same for batched statement execution. PostgreSQL just cannot handle datatype
> flips right in the middle of the batch. It is handled in the pgjdbc driver,
> so it cuts batch in several sub batches, so it becomes less efficient.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-1341) Improve mechanism for client/server to unwrap protobuf RPC message
[
https://issues.apache.org/jira/browse/CALCITE-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-1341:
Fix Version/s: (was: avatica-1.12.0)
avatica-1.13.0
> Improve mechanism for client/server to unwrap protobuf RPC message
> --
>
> Key: CALCITE-1341
> URL: https://issues.apache.org/jira/browse/CALCITE-1341
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: avatica-1.13.0
>
>
> We just ran into a funny bug in PHOENIX-3136 as a fallout of some changes
> which relocated Avatica classes.
> Because the Avatica RPC classes were also relocated (from
> org.apache.calcite.avatica to org.apache.phoenix.org.apache.calcite.avatica),
> clients of an older version could no longer communicate with a server of the
> newer version (and vice versa). This stems from a decision made where the
> wire API included the class name of the Request and Response Java protobuf
> class in the message. The server would send back the Response class name with
> the relocated name, but the client would not know what that class is (because
> it doesn't have the same relocation). In other words, the current protobuf
> serialization approach requires that Avatica classes are not shaded and
> relocated.
> The JSON serialization doesn't have this problem because it uses the
> {{JsonSubType}} Jackson annotation to map the Request/Response class to a
> logical name (e.g. OpenConnectionResponse to openConnection).
> We could do a similar approach for protobuf that the JSON serialization does
> (maintain this mapping and guarantee that it is not changed incompatibly).
> Long-term, I believe I'd like to see specific Requests dispatched to certain
> URLs (instead of all HTTP requests send to {{/}}) and do away with this
> additional logic in the serialization layer, but I'm not sure if we have to
> re-architect the URL scheme just to fix this issue in the near-term.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-1811) Work around "latest" tag for Docker images
[
https://issues.apache.org/jira/browse/CALCITE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-1811:
Fix Version/s: (was: avatica-1.12.0)
avatica-1.13.0
> Work around "latest" tag for Docker images
> --
>
> Key: CALCITE-1811
> URL: https://issues.apache.org/jira/browse/CALCITE-1811
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.10.0
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: avatica-1.13.0
>
>
> One wrinkle with the dockerhub integration with the ASF is that we only get a
> tag for the explicit version we released (e.g. 1.10.0).
> However, in the other Dockerfiles we have in the 1.10.0 release, I had
> (incorrectly) relied on that. Need to come up with a plan for how to better
> manage this in the future. I think that we need to just have {{FROM
> apache/calcite-avatica:$tag}} everywhere, relying on the parent eventually
> being published to dockerhub by the ASF infra.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-1350) Avoid closeConnection when openConnection doesn't finish/succeed
[ https://issues.apache.org/jira/browse/CALCITE-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-1350: Fix Version/s: (was: avatica-1.12.0) avatica-1.13.0 > Avoid closeConnection when openConnection doesn't finish/succeed > > > Key: CALCITE-1350 > URL: https://issues.apache.org/jira/browse/CALCITE-1350 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.13.0 > > > I've noticed during testing of Avatica, often times when SPNEGO > authentication is misconfigured, the client will get stuck in > openConnection(). > If we consider sqlline and the user control-C's it, sqlline will try to close > the driver as well which would do a closeConnection() (which would also > obviously fail). > I believe we should be able to short-circuit the the closeConnection() when > we know that the openConnection() didn't succeed properly. > Another scenario is when the Avatica server is down. openConnection will > fail, but we'll still attempt the closeConnection on exit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1316) Better control over retried operations in Avatica client
[ https://issues.apache.org/jira/browse/CALCITE-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-1316: Fix Version/s: (was: avatica-1.12.0) avatica-1.13.0 > Better control over retried operations in Avatica client > > > Key: CALCITE-1316 > URL: https://issues.apache.org/jira/browse/CALCITE-1316 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.13.0 > > > We have at least two places in the Avatica client now where we will try to > re-issue "RPCs" in the attempt to work seamlessly with load-balanced servers. > Between these two places, we have finite retries, infinite retries and no > standardized back-off strategies. We should try to centralize this into one > place and make sure that users can override the logic, heaven forbid they > come up with some situation where it's necessary. > Need to investigate the retry-loops we have in the Avatica client now, > categorize the loops and come up with a minimal set of knobs to configure the > retries, expose those knobs in the JDBC URL string options, and update the > documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1286) Create self-contained test-harness for TCK
[ https://issues.apache.org/jira/browse/CALCITE-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-1286: Fix Version/s: (was: avatica-1.12.0) avatica-1.13.0 > Create self-contained test-harness for TCK > -- > > Key: CALCITE-1286 > URL: https://issues.apache.org/jira/browse/CALCITE-1286 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.13.0 > > > Should make a Vagrant VM or a Docker image which is capable of automatically > running the Avatica TCK. > Ideally, running the TCK should be as simple as a single command. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2289) Javadoc - HTML5
[ https://issues.apache.org/jira/browse/CALCITE-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-2289: Fix Version/s: (was: avatica-1.12.0) avatica-1.13.0 > Javadoc - HTML5 > --- > > Key: CALCITE-2289 > URL: https://issues.apache.org/jira/browse/CALCITE-2289 > Project: Calcite > Issue Type: Improvement > Components: avatica, core >Affects Versions: avatica-1.12.0, 1.17.0 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Minor > Fix For: 1.17.0, avatica-1.13.0 > > > CALCITE-2225 and CALCITE-2272 tried to enable "-html5" flag with > "". This needs to be changed to "". > Furthermore "-html5" only works on jdk9 or greater so need to add a profile > to fix this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-1928) Calling previous() on a ResultSet that came from an Array gives NullPointerException
[ https://issues.apache.org/jira/browse/CALCITE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang updated CALCITE-1928: Fix Version/s: (was: avatica-1.12.0) avatica-1.13.0 > Calling previous() on a ResultSet that came from an Array gives > NullPointerException > > > Key: CALCITE-1928 > URL: https://issues.apache.org/jira/browse/CALCITE-1928 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: avatica-1.13.0 > > > Calling previous() on a ResultSet that came from an Array gives > NullPointerException. I broke this when I committed CALCITE-1902 and changed > 'Helper.INSTANCE' to 'statement.connection.helper', forgetting that > 'statement' can be null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2330) Release Avatica 1.12
[ https://issues.apache.org/jira/browse/CALCITE-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francis Chuang resolved CALCITE-2330. - Resolution: Fixed > Release Avatica 1.12 > > > Key: CALCITE-2330 > URL: https://issues.apache.org/jira/browse/CALCITE-2330 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Julian Hyde >Assignee: Francis Chuang >Priority: Major > Fix For: avatica-1.12.0 > > > Release Avatica 1.12. > We are targeting the second week of June for release; last release (1.11) was > March 2018 and the one before (1.10) that was May 2017. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2381) Update HOWTOs to clarify a few gotchas
Francis Chuang created CALCITE-2381: --- Summary: Update HOWTOs to clarify a few gotchas Key: CALCITE-2381 URL: https://issues.apache.org/jira/browse/CALCITE-2381 Project: Calcite Issue Type: Improvement Components: avatica, core Reporter: Francis Chuang Assignee: Francis Chuang Fix For: avatica-1.13.0, 1.17.0 Some issues I ran into while releasing Avatica 1.12.0 that should be clarified in the HOWTO document on the website: # GPG signs using a default key (I think this is the first key, if no default is set). I had multiple keys and my Apache key was not my first key. # I was not 100% sure that `-DdevelopmentVersion` should be the version after the current release. # It took a while to work out how to authenticate against Apache's maven repo. See [http://www.apache.org/dev/publishing-maven-artifacts.html#dev-env] for solution The HOWTO for Calcite should also be updated to aid future release managers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2368) Fix misc.iq and scalar.iq quidem unit tests failures on Windows
[
https://issues.apache.org/jira/browse/CALCITE-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522978#comment-16522978
]
Julian Hyde commented on CALCITE-2368:
--
Thanks for fixing this. I managed to track down the same cause on Friday, but
it took me several hours to work back from the de-correlation algorithm to
THREAD_EXPAND to CoreQuidemTest. For I while I simply could not believe that
the de-correlation algorithm would work differently on Windows. So, I'm
impressed that you found it.
> Fix misc.iq and scalar.iq quidem unit tests failures on Windows
> ---
>
> Key: CALCITE-2368
> URL: https://issues.apache.org/jira/browse/CALCITE-2368
> Project: Calcite
> Issue Type: Bug
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> misc.iq and scalar.iq quidem unit tests fail on Windows but pass on Linux.
> *Problem description*
> Files with quidem tests are discovered in runtime. Some tests, such as
> misc.iq or scalar.iq require setting up {{THREAD_EXPAND}} to true (see
> {{CoreQuidemTest.testSqlMisc()}} and {{CoreQuidemTest.testSqlScalar()}}
> methods).
> Methods, which should be called for concrete quidem tests to set required
> variables are discovered using the filename.
> Code replaces character {{'/'}} in the filepath, but in the case of Windows
> in the path was path separator char for Windows.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2365) Calcite is not compiled after bumping Avatica version to 1.12.0
[ https://issues.apache.org/jira/browse/CALCITE-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Nuyanzin updated CALCITE-2365: - Description: I guess the main reason is CALCITE-2219. tried to fix it here https://github.com/apache/calcite/compare/master...snuyanzin:CALCITE_AVATICA_12_UPDATE however there are at least 2 issues which are not fixed but only workarounded # _org.apache.calcite.test.LatticeTest#testGroupByEmpty3_ connection pool factory is used however 3 methods (explainContains, and 2 returnsUnordered ) lead to _org.apache.calcite.test.CalciteAssert#assertQuery_ which closes connections without paying attention if its from pool or not # the same test. mats updated in explainplan and execute => that is why finally size is 6. # test from core/src/test/resources/sql/misc.iq starts failing as the result of CALCITE-1884 it would be nice to have some advice at least relating to first 2 bullets to fix it in a better way was: I guess the main reason is CALCITE-2219. tried to fix it here https://github.com/apache/calcite/compare/master...snuyanzin:CALCITE_AVATICA_12_UPDATE however there are at least 2 issues which are not fixed but only workarounded # _org.apache.calcite.test.LatticeTest#testGroupByEmpty3_ connection pool factory is used however 3 methods (explainContains, and 2 returnsUnordered ) lead to _org.apache.calcite.test.CalciteAssert#assertQuery_ which closes connections without paying attention if its from pool or not # the same test. mats updated in explainplan and execute => that is why finally size is 6. # strange but only now the test from core/src/test/resources/sql/misc.iq starts failing. Logically because of difference in data it must have failed earlier it would be nice to have some advice at least relating to first 2 bullets to fix it in a better way > Calcite is not compiled after bumping Avatica version to 1.12.0 > --- > > Key: CALCITE-2365 > URL: https://issues.apache.org/jira/browse/CALCITE-2365 > Project: Calcite > Issue Type: Bug >Reporter: Sergey Nuyanzin >Assignee: Julian Hyde >Priority: Major > > I guess the main reason is CALCITE-2219. > tried to fix it here > https://github.com/apache/calcite/compare/master...snuyanzin:CALCITE_AVATICA_12_UPDATE > however there are at least 2 issues which are not fixed but only workarounded > # _org.apache.calcite.test.LatticeTest#testGroupByEmpty3_ connection pool > factory is used however 3 methods (explainContains, and 2 returnsUnordered ) > lead to _org.apache.calcite.test.CalciteAssert#assertQuery_ which closes > connections without paying attention if its from pool or not > # the same test. mats updated in explainplan and execute => that is why > finally size is 6. > # test from core/src/test/resources/sql/misc.iq starts failing as the result > of CALCITE-1884 > it would be nice to have some advice at least relating to first 2 bullets to > fix it in a better way -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2365) Calcite is not compiled after bumping Avatica version to 1.12.0
[
https://issues.apache.org/jira/browse/CALCITE-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522923#comment-16522923
]
Sergey Nuyanzin commented on CALCITE-2365:
--
about {quote}strange but only now the test from
core/src/test/resources/sql/misc.iq starts failing. Logically because of
difference in data it must have failed earlier{quote} finally i identified the
reason. It is the "side effect" of CALCITE-1884. Here there are also failures
only for dates before Gregorian cut overs. + If rollback changes from
CALCITE-1884 the test will pass.
updated in description
> Calcite is not compiled after bumping Avatica version to 1.12.0
> ---
>
> Key: CALCITE-2365
> URL: https://issues.apache.org/jira/browse/CALCITE-2365
> Project: Calcite
> Issue Type: Bug
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
>
> I guess the main reason is CALCITE-2219.
> tried to fix it here
> https://github.com/apache/calcite/compare/master...snuyanzin:CALCITE_AVATICA_12_UPDATE
> however there are at least 2 issues which are not fixed but only workarounded
> # _org.apache.calcite.test.LatticeTest#testGroupByEmpty3_ connection pool
> factory is used however 3 methods (explainContains, and 2 returnsUnordered )
> lead to _org.apache.calcite.test.CalciteAssert#assertQuery_ which closes
> connections without paying attention if its from pool or not
> # the same test. mats updated in explainplan and execute => that is why
> finally size is 6.
> # strange but only now the test from core/src/test/resources/sql/misc.iq
> starts failing. Logically because of difference in data it must have failed
> earlier
> it would be nice to have some advice at least relating to first 2 bullets to
> fix it in a better way
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[ https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2339: - Component/s: jdbc-adapter > JDBC adapter should transform timestamp arithmetic for target database > --- > > Key: CALCITE-2339 > URL: https://issues.apache.org/jira/browse/CALCITE-2339 > Project: Calcite > Issue Type: Bug > Components: jdbc-adapter >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: 1.17.0 > > Attachments: Datetime Addition - Calcite.pdf > > > JDBC adapter should transform timestamp arithmetic for target database. > There are two ways in Calcite to add intervals to timestamps: the > TIMESTAMP_ADD function and the " + " operator. > The attached document (authored by James Doung) describes their pros and cons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[ https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522722#comment-16522722 ] Julian Hyde commented on CALCITE-2339: -- Will try to review and merge before 1.17. > JDBC adapter should transform timestamp arithmetic for target database > --- > > Key: CALCITE-2339 > URL: https://issues.apache.org/jira/browse/CALCITE-2339 > Project: Calcite > Issue Type: Bug > Components: jdbc-adapter >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: 1.17.0 > > Attachments: Datetime Addition - Calcite.pdf > > > JDBC adapter should transform timestamp arithmetic for target database. > There are two ways in Calcite to add intervals to timestamps: the > TIMESTAMP_ADD function and the " + " operator. > The attached document (authored by James Doung) describes their pros and cons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2339) JDBC adapter should transform timestamp arithmetic for target database
[ https://issues.apache.org/jira/browse/CALCITE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-2339: - Fix Version/s: 1.17.0 > JDBC adapter should transform timestamp arithmetic for target database > --- > > Key: CALCITE-2339 > URL: https://issues.apache.org/jira/browse/CALCITE-2339 > Project: Calcite > Issue Type: Bug > Components: jdbc-adapter >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Fix For: 1.17.0 > > Attachments: Datetime Addition - Calcite.pdf > > > JDBC adapter should transform timestamp arithmetic for target database. > There are two ways in Calcite to add intervals to timestamps: the > TIMESTAMP_ADD function and the " + " operator. > The attached document (authored by James Doung) describes their pros and cons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2363) Refactor RelShuttle not to depend on structures of RelNodes
[ https://issues.apache.org/jira/browse/CALCITE-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522676#comment-16522676 ] Julian Hyde commented on CALCITE-2363: -- I took a quick look. Looks OK, albeit a bit more verbose, and yes, it does break compatibility. I will review more thoroughly, but first I would like someone else to review. Is this change a net improvement? > Refactor RelShuttle not to depend on structures of RelNodes > --- > > Key: CALCITE-2363 > URL: https://issues.apache.org/jira/browse/CALCITE-2363 > Project: Calcite > Issue Type: Improvement >Reporter: Teruyoshi Zenmyo >Assignee: Julian Hyde >Priority: Major > > Currently, RelShuttle implementations depends on the structures of RelNodes. > For instance, RelShuttleImp.visit(LogicalAggregate aggregate) knows the first > element of getInput() is the next element to be visited. > [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/RelShuttleImpl.java#L75] > > By this refactoring, implementations of RelShuttle will become free from > invoking super.visit methods. > https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql2rel/CorrelationReferenceFinder.java#L61 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2380) javadoc failures for some adapters
Andrei Sereda created CALCITE-2380:
--
Summary: javadoc failures for some adapters
Key: CALCITE-2380
URL: https://issues.apache.org/jira/browse/CALCITE-2380
Project: Calcite
Issue Type: Bug
Reporter: Andrei Sereda
Assignee: Julian Hyde
javadoc generation fails for some adapters.
Commands to reproduce:
{code:java}
$ mvn -DskipTests clean javadoc:javadoc javadoc:test-javadoc
$ mvn -DskipTests clean site{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2379) CVSS dependency-check-maven fails for calcite-spark module
Volodymyr Vysotskyi created CALCITE-2379:
Summary: CVSS dependency-check-maven fails for calcite-spark module
Key: CALCITE-2379
URL: https://issues.apache.org/jira/browse/CALCITE-2379
Project: Calcite
Issue Type: Bug
Reporter: Volodymyr Vysotskyi
Assignee: Julian Hyde
Check for vulnerabilities among dependencies fails for {{calcite-spark}} module.
Output for "{{mvn install -Ppedantic -DskipTests=true}}":
{noformat}
One or more dependencies were identified with known vulnerabilities in Calcite
Spark:
jackson-databind-2.9.4.jar (com.fasterxml.jackson.core:jackson-databind:2.9.4,
cpe:/a:fasterxml:jackson-databind:2.9.4, cpe:/a:fasterxml:jackson:2.9.4) :
CVE-2018-7489
protobuf-java-3.3.0.jar (com.google.protobuf:protobuf-java:3.3.0,
cpe:/a:google:protobuf:3.3.0) : CVE-2015-5237
commons-beanutils-core-1.8.0.jar
(commons-beanutils:commons-beanutils-core:1.8.0,
cpe:/a:apache:commons_beanutils:1.8.0) : CVE-2014-0114
commons-beanutils-1.7.0.jar (commons-beanutils:commons-beanutils:1.7.0,
cpe:/a:apache:commons_beanutils:1.7.0) : CVE-2014-0114
commons-httpclient-3.1.jar (commons-httpclient:commons-httpclient:3.1,
cpe:/a:apache:commons-httpclient:3.1, cpe:/a:apache:httpclient:3.1) :
CVE-2015-5262, CVE-2014-3577
javax.annotation-api-1.2.jar (cpe:/a:oracle:glassfish:1.2,
javax.annotation:javax.annotation-api:1.2) : CVE-2015-2808, CVE-2013-2566
mail-1.4.7.jar (cpe:/a:mail_project:mail:1.4.7, javax.mail:mail:1.4.7) :
CVE-2015-9097
validation-api-1.1.0.Final.jar (cpe:/a:bean_project:bean:7.x-1.1::~~~drupal~~,
javax.validation:validation-api:1.1.0.Final) : CVE-2013-4499
jaxb-api-2.2.2.jar (cpe:/a:fish:fish:2.2.2, cpe:/a:oracle:glassfish:2.2.2,
javax.xml.bind:jaxb-api:2.2.2) : CVE-2015-2808, CVE-2013-2566
pyrolite-4.13.jar (cpe:/a:pickle:pickle:4.13, net.razorvine:pyrolite:4.13) :
CVE-2007-1100
py4j-0.10.4.jar (cpe:/a:python:python:0.10.4,
cpe:/a:python_software_foundation:python:0.10.4, net.sf.py4j:py4j:0.10.4) :
CVE-2018-130, CVE-2017-18207, CVE-2017-17522, CVE-2017-1000158,
CVE-2016-5699, CVE-2016-5636, CVE-2016-1494, CVE-2016-0772, CVE-2015-5652,
CVE-2014-7185, CVE-2014-3539, CVE-2013-7440, CVE-2013-7338, CVE-2012-1150,
CVE-2012-0845, CVE-2011-4940, CVE-2010-3492, CVE-2008-5983, CVE-2008-3143,
CVE-2008-3142, CVE-2008-2315, CVE-2008-1887, CVE-2008-1721, CVE-2008-1679,
CVE-2007-4559, CVE-2006-1542, CVE-2002-1119
avro-mapred-1.7.7-hadoop2.jar (cpe:/a:apache:hadoop:1.7.7,
org.apache.avro:avro-mapred:1.7.7) : CVE-2017-3162, CVE-2017-3161, CVE-2016-5001
curator-recipes-2.6.0.jar (cpe:/a:apache:zookeeper:2.6.0,
org.apache.curator:curator-recipes:2.6.0) : CVE-2016-5017, CVE-2014-0085
api-util-1.0.0-M20.jar (cpe:/a:apache:directory_ldap_api:1.0.0.m30,
org.apache.directory.api:api-util:1.0.0-M20) : CVE-2015-3250
xbean-asm5-shaded-4.4.jar (cpe:/a:apache:geronimo:4.4) : CVE-2008-0732
zookeeper-3.4.6.jar (cpe:/a:apache:zookeeper:3.4.6,
org.apache.zookeeper:zookeeper:3.4.6) : CVE-2017-5637, CVE-2016-5017,
CVE-2014-0085
jackson-xc-1.9.13.jar (cpe:/a:fasterxml:jackson-databind:1.9.13,
cpe:/a:fasterxml:jackson:1.9.13, org.codehaus.jackson:jackson-xc:1.9.13) :
CVE-2018-5968, CVE-2017-17485
jetty-http-9.2.19.v20160908.jar (cpe:/a:eclipse:jetty:9.2.19.v20160908,
cpe:/a:jetty:jetty:9.2.19.v20160908,
org.eclipse.jetty:jetty-http:9.2.19.v20160908) : CVE-2017-9735
jetty-util-6.1.26.jar (cpe:/a:jetty:jetty:6.1.26, cpe:/a:mortbay:jetty:6.1.26,
cpe:/a:mortbay_jetty:jetty:6.1.26, org.mortbay.jetty:jetty-util:6.1.26) :
CVE-2011-4461
unused-1.0.0.jar (cpe:/a:apache:spark:1.0.0,
org.spark-project.spark:unused:1.0.0) : CVE-2017-7678
xz-1.0.jar (cpe:/a:tukaani:xz:1.0, org.tukaani:xz:1.0) : CVE-2015-4035
serializer-2.7.1.jar (cpe:/a:apache:xalan-java:2.7.1, xalan:serializer:2.7.1) :
CVE-2014-0107
xalan-2.7.1.jar (cpe:/a:apache:xalan-java:2.7.1, xalan:xalan:2.7.1) :
CVE-2014-0107
xercesImpl-2.9.1.jar (cpe:/a:apache:xerces2_java:2.9.1,
xerces:xercesImpl:2.9.1) : CVE-2012-0881
htrace-core-3.1.0-incubating.jar/META-INF/maven/com.fasterxml.jackson.core/jackson-databind/pom.xml
(com.fasterxml.jackson.core:jackson-databind:2.4.0,
cpe:/a:fasterxml:jackson-databind:2.4.0, cpe:/a:fasterxml:jackson:2.4.0) :
CVE-2018-7489, CVE-2018-5968, CVE-2017-7525, CVE-2017-17485, CVE-2017-15095
spark-core_2.10-2.2.0.jar/META-INF/maven/org.eclipse.jetty/jetty-plus/pom.xml
(cpe:/a:eclipse:jetty:9.3.11.v20160721, cpe:/a:jetty:jetty:9.3.11.v20160721,
org.eclipse.jetty:jetty-plus:9.3.11.v20160721) : CVE-2017-9735
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2291) Add rule to push Project past Correlate
[
https://issues.apache.org/jira/browse/CALCITE-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522190#comment-16522190
]
Volodymyr Vysotskyi commented on CALCITE-2291:
--
[~cshi], I have added [~HanumathRao]'s fix for Unnest and added fixes for this
rule with ANTI and SEMI correlate and fix to update {{RelDataType}} for
{{RexCorrelVariable}} when the rule is applied.
Could you please review these changes in my branch
[CALCITE-2291|https://github.com/vvysotskyi/calcite/tree/CALCITE-2291]?
If all is ok, I think we can merge it to the master.
> Add rule to push Project past Correlate
> ---
>
> Key: CALCITE-2291
> URL: https://issues.apache.org/jira/browse/CALCITE-2291
> Project: Calcite
> Issue Type: Bug
>Reporter: Chunhui Shi
>Assignee: Julian Hyde
>Priority: Major
>
> Correlate is not derived from Join so we need a rule similar to
> ProjectJoinTransposeRule to push Project to under Correlate.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
