[jira] [Commented] (CALCITE-2355) Multiset operations do not work as expected
[
https://issues.apache.org/jira/browse/CALCITE-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16509277#comment-16509277
]
Julian Hyde commented on CALCITE-2355:
--
I reviewed. Nice work, but one small bug. I wrote a test in operator.iq:
{noformat}
values multiset ['a', 'c', 'a'] multiset except multiset ['a'];
++
| EXPR$0 |
++
| [c, a] |
++
(1 row)
!ok
{noformat}
It should return [c, a] but actually returns [c]. I think there is a problem in
the SqlFunctions.submultisetExceptAll.
> Multiset operations do not work as expected
> ---
>
> Key: CALCITE-2355
> URL: https://issues.apache.org/jira/browse/CALCITE-2355
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
>
> While working on https://issues.apache.org/jira/browse/FLINK-4542 I realized
> that most of the multiset operations do not work and skipped in tests with
> {code}if (TODO) {code}. So here I propose to fix it.
> Here it is my branch with fixes and tests
> Currently it is done for
> {noformat}
> IS A SET
> IS NOT A SET
> IS EMPTY
> IS NOT EMPTY
> MEMBER OF
> MULTISET INTERSECT
> MULTISET INTERSECT ALL
> MULTISET UNION
> MULTISET UNION ALL
> MULTISET EXCEPT
> MULTISET EXCEPT ALL
> SUBMULTISET OF
> NOT SUBMULTISET OF
> {noformat}
> may be the only one which is not done yet is FUSION
> by the way I have a question: is it ok that default case for MULTISET
> INTERSECT/UNION /EXCEPT is DISTINCT
> ([here|https://github.com/apache/calcite/blob/2179f8e87f4179e79e238da3c6c868c315c49e56/core/src/main/codegen/templates/Parser.jj#L5332]
> ) ? At the same time Oracle behaves in the opposite way (e.g. here
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/operators006.htm)
> https://github.com/apache/calcite/compare/master...snuyanzin:CALCITE_MULTISETS
> I can make a PR if nobody minds
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2358) Use null literal instead of empty string as argument for timestamp_parse Druid expression
slim bouguerra created CALCITE-2358:
---
Summary: Use null literal instead of empty string as argument for
timestamp_parse Druid expression
Key: CALCITE-2358
URL: https://issues.apache.org/jira/browse/CALCITE-2358
Project: Calcite
Issue Type: Bug
Components: druid
Reporter: slim bouguerra
Assignee: slim bouguerra
With the new ability to support null values in Druid, empty string is not equal
to null anymore.
To enable auto format parser {code}timestamp_parser{code} Druid function
expects null literal as format argument.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2358) Use null literal instead of empty string as argument for timestamp_parse Druid expression
[
https://issues.apache.org/jira/browse/CALCITE-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
slim bouguerra updated CALCITE-2358:
Description:
With the new ability to support null values in Druid, empty string is not equal
to null anymore.
To enable auto format parser {code}timestamp_parse{code} Druid function expects
null literal as format argument.
was:
With the new ability to support null values in Druid, empty string is not equal
to null anymore.
To enable auto format parser {code}timestamp_parser{code} Druid function
expects null literal as format argument.
> Use null literal instead of empty string as argument for timestamp_parse
> Druid expression
> -
>
> Key: CALCITE-2358
> URL: https://issues.apache.org/jira/browse/CALCITE-2358
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
>
> With the new ability to support null values in Druid, empty string is not
> equal to null anymore.
> To enable auto format parser {code}timestamp_parse{code} Druid function
> expects null literal as format argument.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2354) How to add existing user-defined functions in Schema
[
https://issues.apache.org/jira/browse/CALCITE-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16509422#comment-16509422
]
Subbarao commented on CALCITE-2354:
---
Iam already having some of the functions in oracle database i.e :user defined
functions like FN_CODE("columnname").Then how can i add these type of already
existing functions in Apache calcite schema.
Can you tell me how to solve this task.Last one week onwards searching.If iam
having some existing user defined functions like FN_code(" ") .then how to add
schema in calcite and also when iam writing the sql query like
"select Fn_Code(caseno) from casedata";
It will be showing no match found for functions_signature.
> How to add existing user-defined functions in Schema
>
>
> Key: CALCITE-2354
> URL: https://issues.apache.org/jira/browse/CALCITE-2354
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Reporter: Subbarao
>Assignee: Julian Hyde
>Priority: Critical
>
> Iam already having some of the functions in oracle database i.e :user defined
> functions like FN_CODE("columnname").Then how can i add these type of already
> existing functions in Apache calcite schema
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2319) Druid Expressions - Output Type of Boolean expressions should be set to LONG.
[
https://issues.apache.org/jira/browse/CALCITE-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16509483#comment-16509483
]
Nishant Bangarwa commented on CALCITE-2319:
---
[~julianhyde] If there are no additional comments, please merge.
> Druid Expressions - Output Type of Boolean expressions should be set to LONG.
> -
>
> Key: CALCITE-2319
> URL: https://issues.apache.org/jira/browse/CALCITE-2319
> Project: Calcite
> Issue Type: Bug
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> Sample Query -
> {code}
> SELECT \"product_id\" > 1000 as pid_category, COUNT(\"store_sales\") FROM
> FOODMART_TABLE GROUP BY \"product_id\" > 1000";
> {code}
> For the above query output type of virtual column is set to string whereas it
> should be set to float as druid expression return type is float.
> {code}
> "{"queryType":"groupBy","dataSource":"foodmart","granularity":"all","dimensions":[{"type":"default","dimension":"vc","outputName":"vc","outputType":"STRING"}],"virtualColumns":[{"type":"expression","name":"vc","expression":"(CAST(\"product_id\",
> 'LONG') >
> 1000)","outputType":"FLOAT"}],"limitSpec":{"type":"default"},"aggregations":[{"type":"filtered","filter":{"type":"not","field":{"type":"selector","dimension":"store_sales","value":null}},"aggregator":{"type":"count","name":"EXPR$1","fieldName":"store_sales"}}],"intervals":["1900-01-09T00:00:00.000Z/2992-01-10T00:00:00.000Z"]}"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2358) Use null literal instead of empty string as argument for timestamp_parse Druid expression
[
https://issues.apache.org/jira/browse/CALCITE-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
slim bouguerra updated CALCITE-2358:
Description:
With the new ability to support null values in Druid, empty string is not equal
to null anymore.
To enable auto format parser {code}timestamp_parse{code} Druid function expects
null literal as format argument.
I have added a connection config parameter to allow smooth transition from old
Druid version to version 0.13.0 and above.
was:
With the new ability to support null values in Druid, empty string is not equal
to null anymore.
To enable auto format parser {code}timestamp_parse{code} Druid function expects
null literal as format argument.
> Use null literal instead of empty string as argument for timestamp_parse
> Druid expression
> -
>
> Key: CALCITE-2358
> URL: https://issues.apache.org/jira/browse/CALCITE-2358
> Project: Calcite
> Issue Type: Bug
> Components: druid
>Reporter: slim bouguerra
>Assignee: slim bouguerra
>Priority: Major
>
> With the new ability to support null values in Druid, empty string is not
> equal to null anymore.
> To enable auto format parser {code}timestamp_parse{code} Druid function
> expects null literal as format argument.
> I have added a connection config parameter to allow smooth transition from
> old Druid version to version 0.13.0 and above.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2359) Inconsistent behavior when casting interval literals to integer
James Duong created CALCITE-2359: Summary: Inconsistent behavior when casting interval literals to integer Key: CALCITE-2359 URL: https://issues.apache.org/jira/browse/CALCITE-2359 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.17.0 Reporter: James Duong Assignee: Julian Hyde Ensure casting intervals to integers always returns the result in terms of the trailing unit. Currently we have the following behavior: - Casting a standalone day interval literal returns results in terms of the field. - Casting a standalone year interval literal returned results in terms of months. - Casting a day interval expression returned results in terms of milliseconds. - Casting a year interval expression returned results in terms of months. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2359) Inconsistent behavior when casting interval literals to integer
[ https://issues.apache.org/jira/browse/CALCITE-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16509945#comment-16509945 ] James Duong commented on CALCITE-2359: -- Pull request: https://github.com/apache/calcite/pull/730 > Inconsistent behavior when casting interval literals to integer > --- > > Key: CALCITE-2359 > URL: https://issues.apache.org/jira/browse/CALCITE-2359 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: James Duong >Assignee: Julian Hyde >Priority: Major > > Ensure casting intervals to integers always returns the result in terms > of the trailing unit. > Currently we have the following behavior: > - Casting a standalone day interval literal returns results in terms of the > field. > - Casting a standalone year interval literal returned results in terms of > months. > - Casting a day interval expression returned results in terms of milliseconds. > - Casting a year interval expression returned results in terms of months. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2319) Druid Expressions - Output Type of Boolean expressions should be set to LONG.
[
https://issues.apache.org/jira/browse/CALCITE-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510155#comment-16510155
]
Julian Hyde commented on CALCITE-2319:
--
Can you fix the indent of one or two lines, but once you've done that, +1. As
you're a committer you can squash, rebase and merge to master.
> Druid Expressions - Output Type of Boolean expressions should be set to LONG.
> -
>
> Key: CALCITE-2319
> URL: https://issues.apache.org/jira/browse/CALCITE-2319
> Project: Calcite
> Issue Type: Bug
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>
> Sample Query -
> {code}
> SELECT \"product_id\" > 1000 as pid_category, COUNT(\"store_sales\") FROM
> FOODMART_TABLE GROUP BY \"product_id\" > 1000";
> {code}
> For the above query output type of virtual column is set to string whereas it
> should be set to float as druid expression return type is float.
> {code}
> "{"queryType":"groupBy","dataSource":"foodmart","granularity":"all","dimensions":[{"type":"default","dimension":"vc","outputName":"vc","outputType":"STRING"}],"virtualColumns":[{"type":"expression","name":"vc","expression":"(CAST(\"product_id\",
> 'LONG') >
> 1000)","outputType":"FLOAT"}],"limitSpec":{"type":"default"},"aggregations":[{"type":"filtered","filter":{"type":"not","field":{"type":"selector","dimension":"store_sales","value":null}},"aggregator":{"type":"count","name":"EXPR$1","fieldName":"store_sales"}}],"intervals":["1900-01-09T00:00:00.000Z/2992-01-10T00:00:00.000Z"]}"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CALCITE-2324) Extract seconds, minutes from date works not correct in some cases
[
https://issues.apache.org/jira/browse/CALCITE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-2324.
--
Resolution: Fixed
Fix Version/s: 1.17.0
Fixed in
[a9d6cfdf|http://git-wip-us.apache.org/repos/asf/calcite/commit/a9d6cfdf];
thanks for the PR, [~Sergey Nuyanzin]!
> Extract seconds, minutes from date works not correct in some cases
> --
>
> Key: CALCITE-2324
> URL: https://issues.apache.org/jira/browse/CALCITE-2324
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> While working on tests for CALCITE-2303 faced with the next issue (do not fix
> within 2303 as the fix does not need avatica update while 2303 does)
> {code:sql}select extract(second from date '2008-02-23');{code} returns 13
> I guess the issue is known because of the test is present in
> _org.apache.calcite.sql.test.SqlOperatorBaseTest#testExtractDate_ within
> _TODO_ block and with the comment {code:java} if (TODO) {
> // Looks like there is a bug in current execution code which returns 13
> // instead of 0
> tester.checkScalar(
> "extract(second from date '2008-2-23')",
> "0",
> "BIGINT NOT NULL");
> }{code}
> I deep dive into it and realized that the problem is that in case of DATE
> extract works with days + in case of seconds, minute, hours there will be
> used _org.apache.calcite.adapter.enumerable.RexImpTable#getFactor_. And
> finally the result is
> {noformat}number_of_days % 6 / 1000L //for extract seconds{noformat}
> {noformat}number_of_days % 36 / 1000L //for extract minutes{noformat}
> and yes {code}select extract(minute from date '1700-01-01');{code} returns -1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2324) EXTRACT function: HOUR, MINUTE and SECOND parts of a DATE must be zero
[
https://issues.apache.org/jira/browse/CALCITE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2324:
-
Summary: EXTRACT function: HOUR, MINUTE and SECOND parts of a DATE must be
zero (was: Extract seconds, minutes from date works not correct in some cases)
> EXTRACT function: HOUR, MINUTE and SECOND parts of a DATE must be zero
> --
>
> Key: CALCITE-2324
> URL: https://issues.apache.org/jira/browse/CALCITE-2324
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> While working on tests for CALCITE-2303 faced with the next issue (do not fix
> within 2303 as the fix does not need avatica update while 2303 does)
> {code:sql}select extract(second from date '2008-02-23');{code} returns 13
> I guess the issue is known because of the test is present in
> _org.apache.calcite.sql.test.SqlOperatorBaseTest#testExtractDate_ within
> _TODO_ block and with the comment {code:java} if (TODO) {
> // Looks like there is a bug in current execution code which returns 13
> // instead of 0
> tester.checkScalar(
> "extract(second from date '2008-2-23')",
> "0",
> "BIGINT NOT NULL");
> }{code}
> I deep dive into it and realized that the problem is that in case of DATE
> extract works with days + in case of seconds, minute, hours there will be
> used _org.apache.calcite.adapter.enumerable.RexImpTable#getFactor_. And
> finally the result is
> {noformat}number_of_days % 6 / 1000L //for extract seconds{noformat}
> {noformat}number_of_days % 36 / 1000L //for extract minutes{noformat}
> and yes {code}select extract(minute from date '1700-01-01');{code} returns -1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2341) ImmutableBitSetTest fails with JDK11
[ https://issues.apache.org/jira/browse/CALCITE-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510188#comment-16510188 ] Julian Hyde commented on CALCITE-2341: -- [~laurentgo], Hey, it's all good! (More work for you... but much appreciated!) I'm reviewing and testing now. Will commit shortly. > ImmutableBitSetTest fails with JDK11 > > > Key: CALCITE-2341 > URL: https://issues.apache.org/jira/browse/CALCITE-2341 > Project: Calcite > Issue Type: Bug > Components: avatica, core >Reporter: Laurent Goujon >Assignee: Laurent Goujon >Priority: Minor > Fix For: avatica-1.12.0 > > > A error message change in JDK11 causes ImmutableBitSetTest to fail -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2355) Multiset operations do not work as expected
[
https://issues.apache.org/jira/browse/CALCITE-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510204#comment-16510204
]
Sergey Nuyanzin commented on CALCITE-2355:
--
Thank you for your review. Yes you are right the problem was in the mentioned
method
I updated the PR with the specified case and fix for that
https://github.com/apache/calcite/pull/727
however it failed with elastic search jdk11 compilation (others jdks are ok)
which mentioned in mail thread
> Multiset operations do not work as expected
> ---
>
> Key: CALCITE-2355
> URL: https://issues.apache.org/jira/browse/CALCITE-2355
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Sergey Nuyanzin
>Assignee: Julian Hyde
>Priority: Major
>
> While working on https://issues.apache.org/jira/browse/FLINK-4542 I realized
> that most of the multiset operations do not work and skipped in tests with
> {code}if (TODO) {code}. So here I propose to fix it.
> Here it is my branch with fixes and tests
> Currently it is done for
> {noformat}
> IS A SET
> IS NOT A SET
> IS EMPTY
> IS NOT EMPTY
> MEMBER OF
> MULTISET INTERSECT
> MULTISET INTERSECT ALL
> MULTISET UNION
> MULTISET UNION ALL
> MULTISET EXCEPT
> MULTISET EXCEPT ALL
> SUBMULTISET OF
> NOT SUBMULTISET OF
> {noformat}
> may be the only one which is not done yet is FUSION
> by the way I have a question: is it ok that default case for MULTISET
> INTERSECT/UNION /EXCEPT is DISTINCT
> ([here|https://github.com/apache/calcite/blob/2179f8e87f4179e79e238da3c6c868c315c49e56/core/src/main/codegen/templates/Parser.jj#L5332]
> ) ? At the same time Oracle behaves in the opposite way (e.g. here
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/operators006.htm)
> https://github.com/apache/calcite/compare/master...snuyanzin:CALCITE_MULTISETS
> I can make a PR if nobody minds
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2357) Freemarker dependency override issue in fmpp maven plugin
[
https://issues.apache.org/jira/browse/CALCITE-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510207#comment-16510207
]
Julian Hyde commented on CALCITE-2357:
--
https://github.com/apache/calcite/pull/725
> Freemarker dependency override issue in fmpp maven plugin
> -
>
> Key: CALCITE-2357
> URL: https://issues.apache.org/jira/browse/CALCITE-2357
> Project: Calcite
> Issue Type: Bug
> Components: build
>Affects Versions: 1.16.0
>Reporter: vinoyang
>Assignee: Julian Hyde
>Priority: Minor
>
> currently the fmpp-maven-plugin in pom.xml file :
> {code:java}
>
> com.googlecode.fmpp-maven-plugin
> fmpp-maven-plugin
> ${fmpp-maven-plugin.version}
>
>
> org.freemarker
> freemarker
> ${freemarker.version}
>
>
>
> {code}
> build failed in our inner version (can only access inner maven repository but
> can not access public maven repository) shows error log :
> {code:java}
> [ERROR] Failed to execute goal
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate
> (generate-fmpp-sources) on project calcite-core: Execution
> generate-fmpp-sources of goal
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate failed:
> Plugin com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0 or one of its
> dependencies could not be resolved: Failed to collect dependencies at
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:jar:1.0 ->
> net.sourceforge.fmpp:fmpp:jar:0.9.14 ->
> org.freemarker:freemarker:jar:2.3.24-SNAPSHOT: Failed to read artifact
> descriptor for org.freemarker:freemarker:jar:2.3.24-SNAPSHOT: Could not
> transfer artifact org.freemarker:freemarker:pom:2.3.24-SNAPSHOT from/to
> sonatype-nexus-snapshots
> (https://oss.sonatype.org/content/repositories/snapshots): Connect to
> oss.sonatype.org:443 [oss.sonatype.org/127.0.0.1] failed: Connection refused
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate
> (generate-fmpp-sources) on project calcite-core: Execution
> generate-fmpp-sources of goal
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate failed:
> Plugin com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0 or one of its
> dependencies could not be resolved: Failed to collect dependencies at
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:jar:1.0 ->
> net.sourceforge.fmpp:fmpp:jar:0.9.14 ->
> org.freemarker:freemarker:jar:2.3.24-SNAPSHOT
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> generate-fmpp-sources of goal
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate failed:
> Plugin com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0 or one of its
> dependencies could not be resolved: Failed to collect dependencies at
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:jar:1.0 ->
> net.sourceforge.fmpp:fmpp:jar:0.9.14 ->
> org.freemarker:freemarker:jar:2.3.24-SNAPSHOT
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 11 more
> Caused by: org.apache.maven.plugin.PluginResolutionException: Plugin
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0 or one of its
> dependencies could not be resolved: Failed to collect dependencies at
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:jar:1.0 ->
> net.sourceforge.fmpp:fmpp:jar:0.9.14 ->
> org.freemarker:freemarker:jar:2.3.24-SNAPSHOT
> at
> org.apache.maven.plugin
[jira] [Commented] (CALCITE-2285) Support client cert keystore for Avatica Client
[
https://issues.apache.org/jira/browse/CALCITE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510259#comment-16510259
]
ASF GitHub Bot commented on CALCITE-2285:
-
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/calcite-avatica/pull/57#discussion_r194899085
--- Diff:
core/src/main/java/org/apache/calcite/avatica/remote/AvaticaCommonsHttpClientImpl.java
---
@@ -127,11 +121,54 @@ private void initializeClient() {
final String maxCnxnsPerRoute =
System.getProperty(MAX_POOLED_CONNECTION_PER_ROUTE_KEY,
MAX_POOLED_CONNECTION_PER_ROUTE_DEFAULT);
pool.setDefaultMaxPerRoute(Integer.parseInt(maxCnxnsPerRoute));
+ }
-this.authCache = new BasicAuthCache();
+ protected Registry configureSocketFactories() {
+RegistryBuilder registryBuilder =
RegistryBuilder.create();
+configureHttpRegistry(registryBuilder);
+configureHttpsRegistry(registryBuilder);
+return registryBuilder.build();
+ }
-// A single thread-safe HttpClient, pooling connections via the
ConnectionManager
-this.client = HttpClients.custom().setConnectionManager(pool).build();
+ protected void
configureHttpsRegistry(RegistryBuilder
registryBuilder) {
+if (!configureHttpsSocket) {
--- End diff --
Actually, if we look at the URL, then may push this check up to
`configureSocketFactories()` and call only one of `configureHttpRegsitry` and
`configureHttpsRegistry`?
> Support client cert keystore for Avatica Client
> ---
>
> Key: CALCITE-2285
> URL: https://issues.apache.org/jira/browse/CALCITE-2285
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> Currently Avatica only supports adding trust-store in {{SSLContext}} in all
> {{AvaticaHttpClient}} implementations. If keystore support it added, MTLS
> connections can be established as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2285) Support client cert keystore for Avatica Client
[
https://issues.apache.org/jira/browse/CALCITE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510258#comment-16510258
]
ASF GitHub Bot commented on CALCITE-2285:
-
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/calcite-avatica/pull/57#discussion_r194898896
--- Diff:
core/src/main/java/org/apache/calcite/avatica/remote/AvaticaCommonsHttpClientImpl.java
---
@@ -95,29 +103,15 @@ public AvaticaCommonsHttpClientImpl(URL url) {
}
private void initializeClient() {
-SSLConnectionSocketFactory sslFactory = null;
-if (null != truststore && null != truststorePassword) {
- try {
-SSLContext sslcontext = SSLContexts.custom().loadTrustMaterial(
-truststore, truststorePassword.toCharArray()).build();
-
-final HostnameVerifier verifier =
getHostnameVerifier(hostnameVerification);
-
-sslFactory = new SSLConnectionSocketFactory(sslcontext, verifier);
- } catch (Exception e) {
-throw new RuntimeException(e);
- }
-} else {
- LOG.debug("Not configuring HTTPS because of missing
truststore/password");
-}
+socketFactoryRegistry = this.configureSocketFactories();
+configureConnectionPool(socketFactoryRegistry);
+this.authCache = new BasicAuthCache();
+// A single thread-safe HttpClient, pooling connections via the
ConnectionManager
+this.client = HttpClients.custom().setConnectionManager(pool).build();
+ }
-RegistryBuilder registryBuilder =
RegistryBuilder.create();
-registryBuilder.register("http",
PlainConnectionSocketFactory.getSocketFactory());
-// Only register the SSL factory when provided
-if (null != sslFactory) {
- registryBuilder.register("https", sslFactory);
-}
-pool = new PoolingHttpClientConnectionManager(registryBuilder.build());
+ protected void configureConnectionPool(Registry
configureSocketFactory) {
+pool = new PoolingHttpClientConnectionManager(configureSocketFactory);
--- End diff --
meant to be `connectionSocketFactory`?
> Support client cert keystore for Avatica Client
> ---
>
> Key: CALCITE-2285
> URL: https://issues.apache.org/jira/browse/CALCITE-2285
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> Currently Avatica only supports adding trust-store in {{SSLContext}} in all
> {{AvaticaHttpClient}} implementations. If keystore support it added, MTLS
> connections can be established as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2285) Support client cert keystore for Avatica Client
[
https://issues.apache.org/jira/browse/CALCITE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510257#comment-16510257
]
ASF GitHub Bot commented on CALCITE-2285:
-
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/calcite-avatica/pull/57#discussion_r194898638
--- Diff:
core/src/main/java/org/apache/calcite/avatica/remote/AvaticaCommonsHttpClientImpl.java
---
@@ -127,11 +121,54 @@ private void initializeClient() {
final String maxCnxnsPerRoute =
System.getProperty(MAX_POOLED_CONNECTION_PER_ROUTE_KEY,
MAX_POOLED_CONNECTION_PER_ROUTE_DEFAULT);
pool.setDefaultMaxPerRoute(Integer.parseInt(maxCnxnsPerRoute));
+ }
-this.authCache = new BasicAuthCache();
+ protected Registry configureSocketFactories() {
+RegistryBuilder registryBuilder =
RegistryBuilder.create();
+configureHttpRegistry(registryBuilder);
+configureHttpsRegistry(registryBuilder);
+return registryBuilder.build();
+ }
-// A single thread-safe HttpClient, pooling connections via the
ConnectionManager
-this.client = HttpClients.custom().setConnectionManager(pool).build();
+ protected void
configureHttpsRegistry(RegistryBuilder
registryBuilder) {
+if (!configureHttpsSocket) {
--- End diff --
What about looking at the scheme of the URL instead of using "one of" the
TLS configuration options?
> Support client cert keystore for Avatica Client
> ---
>
> Key: CALCITE-2285
> URL: https://issues.apache.org/jira/browse/CALCITE-2285
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> Currently Avatica only supports adding trust-store in {{SSLContext}} in all
> {{AvaticaHttpClient}} implementations. If keystore support it added, MTLS
> connections can be established as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2285) Support client cert keystore for Avatica Client
[
https://issues.apache.org/jira/browse/CALCITE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510268#comment-16510268
]
ASF GitHub Bot commented on CALCITE-2285:
-
Github user karanmehta93 commented on a diff in the pull request:
https://github.com/apache/calcite-avatica/pull/57#discussion_r194900053
--- Diff:
core/src/main/java/org/apache/calcite/avatica/remote/AvaticaCommonsHttpClientImpl.java
---
@@ -95,29 +103,15 @@ public AvaticaCommonsHttpClientImpl(URL url) {
}
private void initializeClient() {
-SSLConnectionSocketFactory sslFactory = null;
-if (null != truststore && null != truststorePassword) {
- try {
-SSLContext sslcontext = SSLContexts.custom().loadTrustMaterial(
-truststore, truststorePassword.toCharArray()).build();
-
-final HostnameVerifier verifier =
getHostnameVerifier(hostnameVerification);
-
-sslFactory = new SSLConnectionSocketFactory(sslcontext, verifier);
- } catch (Exception e) {
-throw new RuntimeException(e);
- }
-} else {
- LOG.debug("Not configuring HTTPS because of missing
truststore/password");
-}
+socketFactoryRegistry = this.configureSocketFactories();
+configureConnectionPool(socketFactoryRegistry);
+this.authCache = new BasicAuthCache();
+// A single thread-safe HttpClient, pooling connections via the
ConnectionManager
+this.client = HttpClients.custom().setConnectionManager(pool).build();
+ }
-RegistryBuilder registryBuilder =
RegistryBuilder.create();
-registryBuilder.register("http",
PlainConnectionSocketFactory.getSocketFactory());
-// Only register the SSL factory when provided
-if (null != sslFactory) {
- registryBuilder.register("https", sslFactory);
-}
-pool = new PoolingHttpClientConnectionManager(registryBuilder.build());
+ protected void configureConnectionPool(Registry
configureSocketFactory) {
+pool = new PoolingHttpClientConnectionManager(configureSocketFactory);
--- End diff --
Oh yes, updated it locally but forgot to push it. Will do.
> Support client cert keystore for Avatica Client
> ---
>
> Key: CALCITE-2285
> URL: https://issues.apache.org/jira/browse/CALCITE-2285
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> Currently Avatica only supports adding trust-store in {{SSLContext}} in all
> {{AvaticaHttpClient}} implementations. If keystore support it added, MTLS
> connections can be established as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2285) Support client cert keystore for Avatica Client
[
https://issues.apache.org/jira/browse/CALCITE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510270#comment-16510270
]
ASF GitHub Bot commented on CALCITE-2285:
-
Github user karanmehta93 commented on a diff in the pull request:
https://github.com/apache/calcite-avatica/pull/57#discussion_r194900551
--- Diff:
core/src/main/java/org/apache/calcite/avatica/remote/AvaticaCommonsHttpClientImpl.java
---
@@ -127,11 +121,54 @@ private void initializeClient() {
final String maxCnxnsPerRoute =
System.getProperty(MAX_POOLED_CONNECTION_PER_ROUTE_KEY,
MAX_POOLED_CONNECTION_PER_ROUTE_DEFAULT);
pool.setDefaultMaxPerRoute(Integer.parseInt(maxCnxnsPerRoute));
+ }
-this.authCache = new BasicAuthCache();
+ protected Registry configureSocketFactories() {
+RegistryBuilder registryBuilder =
RegistryBuilder.create();
+configureHttpRegistry(registryBuilder);
+configureHttpsRegistry(registryBuilder);
+return registryBuilder.build();
+ }
-// A single thread-safe HttpClient, pooling connections via the
ConnectionManager
-this.client = HttpClients.custom().setConnectionManager(pool).build();
+ protected void
configureHttpsRegistry(RegistryBuilder
registryBuilder) {
+if (!configureHttpsSocket) {
--- End diff --
I agree, but sometimes various services can have varied requirements. The
best and simple case is to have either http or https, however I didn't want to
change the original implementation, so I added both of them here as well.
What do you think?
> Support client cert keystore for Avatica Client
> ---
>
> Key: CALCITE-2285
> URL: https://issues.apache.org/jira/browse/CALCITE-2285
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> Currently Avatica only supports adding trust-store in {{SSLContext}} in all
> {{AvaticaHttpClient}} implementations. If keystore support it added, MTLS
> connections can be established as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2285) Support client cert keystore for Avatica Client
[
https://issues.apache.org/jira/browse/CALCITE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510278#comment-16510278
]
ASF GitHub Bot commented on CALCITE-2285:
-
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/calcite-avatica/pull/57#discussion_r194901281
--- Diff:
core/src/main/java/org/apache/calcite/avatica/remote/AvaticaCommonsHttpClientImpl.java
---
@@ -127,11 +121,54 @@ private void initializeClient() {
final String maxCnxnsPerRoute =
System.getProperty(MAX_POOLED_CONNECTION_PER_ROUTE_KEY,
MAX_POOLED_CONNECTION_PER_ROUTE_DEFAULT);
pool.setDefaultMaxPerRoute(Integer.parseInt(maxCnxnsPerRoute));
+ }
-this.authCache = new BasicAuthCache();
+ protected Registry configureSocketFactories() {
+RegistryBuilder registryBuilder =
RegistryBuilder.create();
+configureHttpRegistry(registryBuilder);
+configureHttpsRegistry(registryBuilder);
+return registryBuilder.build();
+ }
-// A single thread-safe HttpClient, pooling connections via the
ConnectionManager
-this.client = HttpClients.custom().setConnectionManager(pool).build();
+ protected void
configureHttpsRegistry(RegistryBuilder
registryBuilder) {
+if (!configureHttpsSocket) {
--- End diff --
I think there's a strong coupling of HttpClient to a specific avatica
server instance ( going off of memory). If that's the case, then there's no
problem in making the determination as to what kind of http client we need to
set up.
> Support client cert keystore for Avatica Client
> ---
>
> Key: CALCITE-2285
> URL: https://issues.apache.org/jira/browse/CALCITE-2285
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> Currently Avatica only supports adding trust-store in {{SSLContext}} in all
> {{AvaticaHttpClient}} implementations. If keystore support it added, MTLS
> connections can be established as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2285) Support client cert keystore for Avatica Client
[
https://issues.apache.org/jira/browse/CALCITE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510316#comment-16510316
]
ASF GitHub Bot commented on CALCITE-2285:
-
Github user karanmehta93 commented on a diff in the pull request:
https://github.com/apache/calcite-avatica/pull/57#discussion_r194906396
--- Diff:
core/src/main/java/org/apache/calcite/avatica/remote/AvaticaCommonsHttpClientImpl.java
---
@@ -127,11 +121,54 @@ private void initializeClient() {
final String maxCnxnsPerRoute =
System.getProperty(MAX_POOLED_CONNECTION_PER_ROUTE_KEY,
MAX_POOLED_CONNECTION_PER_ROUTE_DEFAULT);
pool.setDefaultMaxPerRoute(Integer.parseInt(maxCnxnsPerRoute));
+ }
-this.authCache = new BasicAuthCache();
+ protected Registry configureSocketFactories() {
+RegistryBuilder registryBuilder =
RegistryBuilder.create();
+configureHttpRegistry(registryBuilder);
+configureHttpsRegistry(registryBuilder);
+return registryBuilder.build();
+ }
-// A single thread-safe HttpClient, pooling connections via the
ConnectionManager
-this.client = HttpClients.custom().setConnectionManager(pool).build();
+ protected void
configureHttpsRegistry(RegistryBuilder
registryBuilder) {
+if (!configureHttpsSocket) {
--- End diff --
I looked through the code. That's correct. The `HttpHost` required by
`CloseableHttpClient` is created in the constructor itself. `HttpHost` is the
one that uses the URL provided during the initialization. So there's a tight
coupling here and there will never be a case where both of them will be
together. I will update the code to configure either of these factories
depending on URL prefix as `http` vs `https`. What do you think?
> Support client cert keystore for Avatica Client
> ---
>
> Key: CALCITE-2285
> URL: https://issues.apache.org/jira/browse/CALCITE-2285
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> Currently Avatica only supports adding trust-store in {{SSLContext}} in all
> {{AvaticaHttpClient}} implementations. If keystore support it added, MTLS
> connections can be established as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2285) Support client cert keystore for Avatica Client
[
https://issues.apache.org/jira/browse/CALCITE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510318#comment-16510318
]
ASF GitHub Bot commented on CALCITE-2285:
-
Github user karanmehta93 commented on a diff in the pull request:
https://github.com/apache/calcite-avatica/pull/57#discussion_r194906872
--- Diff:
core/src/main/java/org/apache/calcite/avatica/remote/AvaticaCommonsHttpClientImpl.java
---
@@ -127,11 +121,54 @@ private void initializeClient() {
final String maxCnxnsPerRoute =
System.getProperty(MAX_POOLED_CONNECTION_PER_ROUTE_KEY,
MAX_POOLED_CONNECTION_PER_ROUTE_DEFAULT);
pool.setDefaultMaxPerRoute(Integer.parseInt(maxCnxnsPerRoute));
+ }
-this.authCache = new BasicAuthCache();
+ protected Registry configureSocketFactories() {
+RegistryBuilder registryBuilder =
RegistryBuilder.create();
+configureHttpRegistry(registryBuilder);
+configureHttpsRegistry(registryBuilder);
+return registryBuilder.build();
+ }
-// A single thread-safe HttpClient, pooling connections via the
ConnectionManager
-this.client = HttpClients.custom().setConnectionManager(pool).build();
+ protected void
configureHttpsRegistry(RegistryBuilder
registryBuilder) {
+if (!configureHttpsSocket) {
--- End diff --
Actually I will use `url.getProtocol()` method to handle it for me. Seems
better option.
> Support client cert keystore for Avatica Client
> ---
>
> Key: CALCITE-2285
> URL: https://issues.apache.org/jira/browse/CALCITE-2285
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> Currently Avatica only supports adding trust-store in {{SSLContext}} in all
> {{AvaticaHttpClient}} implementations. If keystore support it added, MTLS
> connections can be established as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2285) Support client cert keystore for Avatica Client
[
https://issues.apache.org/jira/browse/CALCITE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510320#comment-16510320
]
ASF GitHub Bot commented on CALCITE-2285:
-
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/calcite-avatica/pull/57#discussion_r194907083
--- Diff:
core/src/main/java/org/apache/calcite/avatica/remote/AvaticaCommonsHttpClientImpl.java
---
@@ -127,11 +121,54 @@ private void initializeClient() {
final String maxCnxnsPerRoute =
System.getProperty(MAX_POOLED_CONNECTION_PER_ROUTE_KEY,
MAX_POOLED_CONNECTION_PER_ROUTE_DEFAULT);
pool.setDefaultMaxPerRoute(Integer.parseInt(maxCnxnsPerRoute));
+ }
-this.authCache = new BasicAuthCache();
+ protected Registry configureSocketFactories() {
+RegistryBuilder registryBuilder =
RegistryBuilder.create();
+configureHttpRegistry(registryBuilder);
+configureHttpsRegistry(registryBuilder);
+return registryBuilder.build();
+ }
-// A single thread-safe HttpClient, pooling connections via the
ConnectionManager
-this.client = HttpClients.custom().setConnectionManager(pool).build();
+ protected void
configureHttpsRegistry(RegistryBuilder
registryBuilder) {
+if (!configureHttpsSocket) {
--- End diff --
👍
> Support client cert keystore for Avatica Client
> ---
>
> Key: CALCITE-2285
> URL: https://issues.apache.org/jira/browse/CALCITE-2285
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> Currently Avatica only supports adding trust-store in {{SSLContext}} in all
> {{AvaticaHttpClient}} implementations. If keystore support it added, MTLS
> connections can be established as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2285) Support client cert keystore for Avatica Client
[
https://issues.apache.org/jira/browse/CALCITE-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510360#comment-16510360
]
ASF GitHub Bot commented on CALCITE-2285:
-
Github user karanmehta93 commented on the issue:
https://github.com/apache/calcite-avatica/pull/57
Updated the PR. All the tests pass locally.
> Support client cert keystore for Avatica Client
> ---
>
> Key: CALCITE-2285
> URL: https://issues.apache.org/jira/browse/CALCITE-2285
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: avatica-1.12.0
>
>
> Currently Avatica only supports adding trust-store in {{SSLContext}} in all
> {{AvaticaHttpClient}} implementations. If keystore support it added, MTLS
> connections can be established as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2341) ImmutableBitSetTest fails with JDK11
[
https://issues.apache.org/jira/browse/CALCITE-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510411#comment-16510411
]
Julian Hyde commented on CALCITE-2341:
--
Javadoc on JDK 8 doesn't like {{}}. Fixing now.
> ImmutableBitSetTest fails with JDK11
>
>
> Key: CALCITE-2341
> URL: https://issues.apache.org/jira/browse/CALCITE-2341
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Reporter: Laurent Goujon
>Assignee: Laurent Goujon
>Priority: Minor
> Fix For: avatica-1.12.0
>
>
> A error message change in JDK11 causes ImmutableBitSetTest to fail
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2322) Add fetch size support to connection url and JDBC statement
[ https://issues.apache.org/jira/browse/CALCITE-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510412#comment-16510412 ] ASF GitHub Bot commented on CALCITE-2322: - Github user F21 commented on the issue: https://github.com/apache/calcite-avatica/pull/49 @kminder Do you think it would be possible to get this change in by the end of this week? > Add fetch size support to connection url and JDBC statement > --- > > Key: CALCITE-2322 > URL: https://issues.apache.org/jira/browse/CALCITE-2322 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.11.0 >Reporter: Kevin Minder >Assignee: Julian Hyde >Priority: Major > > Currently the remote driver defaults to hard coded fetch size of 100 rows. > When a connection is operating in HTTP mode having such a small fetch size > can add enormous overhead. This is especially true if TLS connections are > used and made worse if each connection flows throw multiple proxies. > Consider that 100K rows returned 100 rows at a time will make 1K HTTP POST > requests. One might say that nobody should ever do that but some tools like > Spotfire may end up doing this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2357) Freemarker dependency override issue in fmpp maven plugin
[
https://issues.apache.org/jira/browse/CALCITE-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-2357.
--
Resolution: Fixed
Fix Version/s: 1.17.0
Fixed in
[e50795a4|http://git-wip-us.apache.org/repos/asf/calcite/commit/e50795a4];
thanks for the PR, [~yanghua]!
> Freemarker dependency override issue in fmpp maven plugin
> -
>
> Key: CALCITE-2357
> URL: https://issues.apache.org/jira/browse/CALCITE-2357
> Project: Calcite
> Issue Type: Bug
> Components: build
>Affects Versions: 1.16.0
>Reporter: vinoyang
>Assignee: Julian Hyde
>Priority: Minor
> Fix For: 1.17.0
>
>
> currently the fmpp-maven-plugin in pom.xml file :
> {code:java}
>
> com.googlecode.fmpp-maven-plugin
> fmpp-maven-plugin
> ${fmpp-maven-plugin.version}
>
>
> org.freemarker
> freemarker
> ${freemarker.version}
>
>
>
> {code}
> build failed in our inner version (can only access inner maven repository but
> can not access public maven repository) shows error log :
> {code:java}
> [ERROR] Failed to execute goal
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate
> (generate-fmpp-sources) on project calcite-core: Execution
> generate-fmpp-sources of goal
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate failed:
> Plugin com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0 or one of its
> dependencies could not be resolved: Failed to collect dependencies at
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:jar:1.0 ->
> net.sourceforge.fmpp:fmpp:jar:0.9.14 ->
> org.freemarker:freemarker:jar:2.3.24-SNAPSHOT: Failed to read artifact
> descriptor for org.freemarker:freemarker:jar:2.3.24-SNAPSHOT: Could not
> transfer artifact org.freemarker:freemarker:pom:2.3.24-SNAPSHOT from/to
> sonatype-nexus-snapshots
> (https://oss.sonatype.org/content/repositories/snapshots): Connect to
> oss.sonatype.org:443 [oss.sonatype.org/127.0.0.1] failed: Connection refused
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate
> (generate-fmpp-sources) on project calcite-core: Execution
> generate-fmpp-sources of goal
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate failed:
> Plugin com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0 or one of its
> dependencies could not be resolved: Failed to collect dependencies at
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:jar:1.0 ->
> net.sourceforge.fmpp:fmpp:jar:0.9.14 ->
> org.freemarker:freemarker:jar:2.3.24-SNAPSHOT
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:185)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:181)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> generate-fmpp-sources of goal
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0:generate failed:
> Plugin com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0 or one of its
> dependencies could not be resolved: Failed to collect dependencies at
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:jar:1.0 ->
> net.sourceforge.fmpp:fmpp:jar:0.9.14 ->
> org.freemarker:freemarker:jar:2.3.24-SNAPSHOT
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 11 more
> Caused by: org.apache.maven.plugin.PluginResolutionException: Plugin
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:1.0 or one of its
> dependencies could not be resolved: Failed to collect dependencies at
> com.googlecode.fmpp-maven-plugin:fmpp-maven-plugin:jar:1.0 ->
> net.sourceforge.fmpp:fmp
[jira] [Resolved] (CALCITE-2341) ImmutableBitSetTest fails with JDK11
[ https://issues.apache.org/jira/browse/CALCITE-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-2341. -- Resolution: Fixed Fix Version/s: 1.17.0 Fixed in Calcite in [03dce133|http://git-wip-us.apache.org/repos/asf/calcite/commit/03dce133]. > ImmutableBitSetTest fails with JDK11 > > > Key: CALCITE-2341 > URL: https://issues.apache.org/jira/browse/CALCITE-2341 > Project: Calcite > Issue Type: Bug > Components: avatica, core >Reporter: Laurent Goujon >Assignee: Laurent Goujon >Priority: Minor > Fix For: avatica-1.12.0, 1.17.0 > > > A error message change in JDK11 causes ImmutableBitSetTest to fail -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CALCITE-2329) Enhance SubQueryRemoveRule to rewrite IN operator with the constant from the left side more optimally
[
https://issues.apache.org/jira/browse/CALCITE-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-2329.
--
Resolution: Fixed
Fix Version/s: 1.17.0
Fixed in
[1ae6a526|http://git-wip-us.apache.org/repos/asf/calcite/commit/1ae6a526].
> Enhance SubQueryRemoveRule to rewrite IN operator with the constant from the
> left side more optimally
> -
>
> Key: CALCITE-2329
> URL: https://issues.apache.org/jira/browse/CALCITE-2329
> Project: Calcite
> Issue Type: Improvement
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> Currently, for queries like this:
> {code:sql}
> select sal from emp where 2 IN (select deptno from dept)
> {code}
> SubQueryRemoveRule rules expand query plan in such a way:
> {noformat}
> LogicalProject(SAL=[$5])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
> LogicalJoin(condition=[=(2, $9)], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(DEPTNO=[$0])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {noformat}
> Since join condition is actually a filter condition, it will be pushed into
> the filter during further planning stages and join with the true condition is
> left.
> But these types of the queries may be rewritten in the same way as EXISTS
> queries:
> {code:sql}
> select sal from emp where EXISTS (select deptno from dept where deptno=2)
> {code}
> with the more optimal plan:
> {noformat}
> LogicalProject(SAL=[$5])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{0}])
> LogicalProject(i=[true])
> LogicalFilter(condition=[=($0, 2)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
