[jira] [Updated] (CALCITE-4905) JdbcCalc does not extend Calc
[
https://issues.apache.org/jira/browse/CALCITE-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4905:
Labels: pull-request-available (was: )
> JdbcCalc does not extend Calc
> -
>
> Key: CALCITE-4905
> URL: https://issues.apache.org/jira/browse/CALCITE-4905
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.28.0
>Reporter: Francesco Gini
>Assignee: Francesco Gini
>Priority: Major
> Labels: pull-request-available
> Attachments: test_with_failing_JdbcCalc_conversion.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{JdbcCalc}} class does not implement Calc. Failing to do that means that
> {{RelToSqlConverter}} cannot translate a plan with {{JdbcCalc}} into sql
> because {{RelToSqlConverter}} expects
> {code:java}
> public Result visit(Calc e){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457824#comment-17457824 ] Julian Hyde commented on CALCITE-4935: -- I'm not an expert on the standalone server or shading. I'd say that option 2 (no need to shade) sounds right, but I don't have a strong opinion. > Avatica standalone-server shades log4j without relocation > - > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > Attachments: screenshot-1.png > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457809#comment-17457809 ] Jacques Nadeau edited comment on CALCITE-4935 at 12/12/21, 4:34 AM: Given [~elserj]'s comments here, it doesn't seem like the target for the standalone server is as a dependency. If that is the case, I think we should close this as won't fix and instead simply add some release notes commenting on the change. As I mentioned above, if a person is using this as a standalone daemon, it would best if we make it as easy (standard) as possible to configure logging. was (Author: jnadeau): Given [~elserj]'s comments here, it doesn't seem like the target for the standalone server is as a dependency. If that is the case, I think we should close this as won't fix and instead simply add some release notes commenting on the change. As I mentioned above, if a person is using this as a standalone daemon, we would make it as easy as possible to configure logging, etc. > Avatica standalone-server shades log4j without relocation > - > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > Attachments: screenshot-1.png > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457809#comment-17457809 ] Jacques Nadeau commented on CALCITE-4935: - Given [~elserj]'s comments here, it doesn't seem like the target for the standalone server is as a dependency. If that is the case, I think we should close this as won't fix and instead simply add some release notes commenting on the change. As I mentioned above, if a person is using this as a standalone daemon, we would make it as easy as possible to configure logging, etc. > Avatica standalone-server shades log4j without relocation > - > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > Attachments: screenshot-1.png > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457795#comment-17457795 ] Josh Elser commented on CALCITE-4935: - The point of the standalone server jar was to give you a way to launch avatica against any database via a "java -cp" command. It makes testing Julian's hsqdb Scott dataset easy, for example. Removing the relocation for slf4j and log4j were to avoid needing to make extra implementations to use standard logger configuration. I don't remember why I had to undo it for Jetty too (but I imagine it was broken). If we do relocate them, we'll have to do the relocation like Stamatis said and also document how you change the logging config. > Avatica standalone-server shades log4j without relocation > - > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > Attachments: screenshot-1.png > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457780#comment-17457780 ] Jacques Nadeau commented on CALCITE-4935: - Hey [~zabetak], You probably need to enable several resource transformers. For maven's shade plugin they are here: https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html. For example, the meta-inf example needs ServicesResourceTransformer. For gradle shadowjar, I'm not sure the similar item. It looks like maybe "mergeServiceFiles()" per https://github.com/johnrengelman/shadow/issues/105 > Avatica standalone-server shades log4j without relocation > - > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > Attachments: screenshot-1.png > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[
https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457779#comment-17457779
]
Stamatis Zampetakis commented on CALCITE-4935:
--
I tend to agree with [~jnadeau] and I think we are in case 2 but it is the
first time that I deal with standalone server so cannot tell for sure what's
the expectations here.
I guess [~elserj] or [~julianhyde] know better how the standalone server is
meant to be consumed.
Indeed relocating log4j2 is not gonna be easy. I was checking a bit more on
this and some problems seems to come from the fact that META-INF/services files
for log4j2 remain untouched while the classes have moved.
{noformat}
jar tf avatica-standalone-server-1.20.0-SNAPSHOT-shadow.jar | grep
"META-INF/services/org.apache.logging"
META-INF/services/org.apache.logging.log4j.spi.Provider
META-INF/services/org.apache.logging.log4j.core.util.ContextDataProvider
META-INF/services/org.apache.logging.log4j.message.ThreadDumpMessage$ThreadInfoFactory
META-INF/services/org.apache.logging.log4j.util.PropertySource
{noformat}
> Avatica standalone-server shades log4j without relocation
> -
>
> Key: CALCITE-4935
> URL: https://issues.apache.org/jira/browse/CALCITE-4935
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Fix For: avatica-1.20.0
>
> Attachments: screenshot-1.png
>
>
> The issue has been found during the vote for avatica-1.20.0 RC0.
> The standalone-server jar in the [staged maven
> repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar]
> contains log4j2 classes but they are not relocated.
> In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all
> relocated to avoid classpath problems with other libraries/apps potentially
> using another log4j2 version.
> It seems that relocation was dropped in possibly unintenionally in
> CALCITE-4152.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1745#comment-1745 ] Jacques Nadeau edited comment on CALCITE-4935 at 12/12/21, 12:09 AM: - I don't really understand the expectation of shading here. Generally speaking, things should be one of the two following options: 1. This is a jar used within another application (far dependency jar). In that case, the standard pattern is to only include slf4j apis (unshaded) and let users bring their own logging implementation. 2. This is a jar used as a standalone server (easy to run/deploy single jar). In that case, there is no reason to shade dependencies as it isn't designed to be run in another application. People should be able to use standard logging configuration patterns. Including logging impl but shading it makes it hard to deal with in #1 and difficult to configure/control logging consistently in #2. That being said, if we really think the impl should be included and shaded (neither 1 nor 2 above), it looks like there may be need to merge some internal log4j2 files using a special transformer. See https://github.com/johnrengelman/shadow/issues/207, https://github.com/edwgiz/maven-shaded-log4j-transformer and https://issues.apache.org/jira/browse/LOG4J2-673. was (Author: jnadeau): I don't really understand the expectation of shading here. Generally speaking, things should be one of the two following options: 1. This is a jar used within another application (far dependency jar). In that case, the standard pattern is to only include slf4j apis (unshaded) and let users bring their own logging implementation. 2. This is a jar used as a standalone server (easy to run/deploy single jar). In that case, there is no reason to shade dependencies as it isn't designed to be run in another application. People should be able to use standard logging configuration patterns. Including logging impl but shading it makes it hard to deal configure/control logging consistently in #1. That being said, if we really think the impl should be included and shaded (neither 1 nor 2 above), it looks like there may be need to merge some internal log4j2 files using a special transformer. See https://github.com/johnrengelman/shadow/issues/207, https://github.com/edwgiz/maven-shaded-log4j-transformer and https://issues.apache.org/jira/browse/LOG4J2-673. > Avatica standalone-server shades log4j without relocation > - > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > Attachments: screenshot-1.png > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1745#comment-1745 ] Jacques Nadeau commented on CALCITE-4935: - I don't really understand the expectation of shading here. Generally speaking, things should be one of the two following options: 1. This is a jar used within another application (far dependency jar). In that case, the standard pattern is to only include slf4j apis (unshaded) and let users bring their own logging implementation. 2. This is a jar used as a standalone server (easy to run/deploy single jar). In that case, there is no reason to shade dependencies as it isn't designed to be run in another application. People should be able to use standard patterns to configure. Including logging impl but shading it makes it hard to deal configure/control logging consistently in #1. That being said, if we really think the impl should be included and shaded (neither 1 nor 2 above), it looks like there may be need to merge some internal log4j2 files using a special transformer. See https://github.com/johnrengelman/shadow/issues/207, https://github.com/edwgiz/maven-shaded-log4j-transformer and https://issues.apache.org/jira/browse/LOG4J2-673. > Avatica standalone-server shades log4j without relocation > - > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > Attachments: screenshot-1.png > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1745#comment-1745 ] Jacques Nadeau edited comment on CALCITE-4935 at 12/12/21, 12:07 AM: - I don't really understand the expectation of shading here. Generally speaking, things should be one of the two following options: 1. This is a jar used within another application (far dependency jar). In that case, the standard pattern is to only include slf4j apis (unshaded) and let users bring their own logging implementation. 2. This is a jar used as a standalone server (easy to run/deploy single jar). In that case, there is no reason to shade dependencies as it isn't designed to be run in another application. People should be able to use standard logging configuration patterns. Including logging impl but shading it makes it hard to deal configure/control logging consistently in #1. That being said, if we really think the impl should be included and shaded (neither 1 nor 2 above), it looks like there may be need to merge some internal log4j2 files using a special transformer. See https://github.com/johnrengelman/shadow/issues/207, https://github.com/edwgiz/maven-shaded-log4j-transformer and https://issues.apache.org/jira/browse/LOG4J2-673. was (Author: jnadeau): I don't really understand the expectation of shading here. Generally speaking, things should be one of the two following options: 1. This is a jar used within another application (far dependency jar). In that case, the standard pattern is to only include slf4j apis (unshaded) and let users bring their own logging implementation. 2. This is a jar used as a standalone server (easy to run/deploy single jar). In that case, there is no reason to shade dependencies as it isn't designed to be run in another application. People should be able to use standard patterns to configure. Including logging impl but shading it makes it hard to deal configure/control logging consistently in #1. That being said, if we really think the impl should be included and shaded (neither 1 nor 2 above), it looks like there may be need to merge some internal log4j2 files using a special transformer. See https://github.com/johnrengelman/shadow/issues/207, https://github.com/edwgiz/maven-shaded-log4j-transformer and https://issues.apache.org/jira/browse/LOG4J2-673. > Avatica standalone-server shades log4j without relocation > - > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > Attachments: screenshot-1.png > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[
https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457771#comment-17457771
]
Stamatis Zampetakis edited comment on CALCITE-4935 at 12/11/21, 11:41 PM:
--
The problem is that simply adding back similar lines for log4j2 does not seem
to work. I tried adding the following to the relocation list:
"org.apache.logging",
"org.slf4j"
or
"org.apache.logging.log4j",
"org.slf4j"
but then when I run the standalone-server I get the following error:
{noformat}
java -jar avatica-standalone-server-1.20.0-SNAPSHOT-shadow.jar -u
"jdbc:super://localhost"
ERROR StatusLogger Log4j2 could not find a logging implementation. Please add
log4j-core to the classpath. Using SimpleLogger to log to the console...
{noformat}
The relocations does take place cause I checked the content of the jar but
something goes wrong at runtime.
was (Author: zabetak):
The problem is that simply adding back similar lines for log4j2 does not seem
to work. I tried adding the following to the relocation list:
"org.apache.logging",
"org.slf4j"
or
"org.apache.logging.log4j",
"org.slf4j"
but then when I run the standalone-server I get the following error:
{noformat}
java -jar avatica-standalone-server-1.20.0-SNAPSHOT-shadow.jar -u
"jdbc:super://localhost"
ERROR StatusLogger Log4j2 could not find a logging implementation. Please add
log4j-core to the classpath. Using SimpleLogger to log to the console...
{noformat}
> Avatica standalone-server shades log4j without relocation
> -
>
> Key: CALCITE-4935
> URL: https://issues.apache.org/jira/browse/CALCITE-4935
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Fix For: avatica-1.20.0
>
> Attachments: screenshot-1.png
>
>
> The issue has been found during the vote for avatica-1.20.0 RC0.
> The standalone-server jar in the [staged maven
> repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar]
> contains log4j2 classes but they are not relocated.
> In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all
> relocated to avoid classpath problems with other libraries/apps potentially
> using another log4j2 version.
> It seems that relocation was dropped in possibly unintenionally in
> CALCITE-4152.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[
https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457771#comment-17457771
]
Stamatis Zampetakis commented on CALCITE-4935:
--
The problem is that simply adding back similar lines for log4j2 does not seem
to work. I tried adding the following to the relocation list:
"org.apache.logging",
"org.slf4j"
or
"org.apache.logging.log4j",
"org.slf4j"
but then when I run the standalone-server I get the following error:
{noformat}
java -jar avatica-standalone-server-1.20.0-SNAPSHOT-shadow.jar -u
"jdbc:super://localhost"
ERROR StatusLogger Log4j2 could not find a logging implementation. Please add
log4j-core to the classpath. Using SimpleLogger to log to the console...
{noformat}
> Avatica standalone-server shades log4j without relocation
> -
>
> Key: CALCITE-4935
> URL: https://issues.apache.org/jira/browse/CALCITE-4935
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Fix For: avatica-1.20.0
>
> Attachments: screenshot-1.png
>
>
> The issue has been found during the vote for avatica-1.20.0 RC0.
> The standalone-server jar in the [staged maven
> repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar]
> contains log4j2 classes but they are not relocated.
> In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all
> relocated to avoid classpath problems with other libraries/apps potentially
> using another log4j2 version.
> It seems that relocation was dropped in possibly unintenionally in
> CALCITE-4152.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Nadeau updated CALCITE-4935: Attachment: screenshot-1.png > Avatica standalone-server shades log4j without relocation > - > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > Attachments: screenshot-1.png > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457757#comment-17457757 ] Jacques Nadeau commented on CALCITE-4935: - [~elserj], I see in the CALCITE-4152 that you removed three lines from the shadowjar implementation. Was that on purpose? Any idea why you did that? !screenshot-1.png! > Avatica standalone-server shades log4j without relocation > - > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > Attachments: screenshot-1.png > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4933) Release Avatica 1.20.0
[ https://issues.apache.org/jira/browse/CALCITE-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457734#comment-17457734 ] Julian Hyde commented on CALCITE-4933: -- Release candidate 0 canceled due to CALCITE-4935. > Release Avatica 1.20.0 > -- > > Key: CALCITE-4933 > URL: https://issues.apache.org/jira/browse/CALCITE-4933 > Project: Calcite > Issue Type: Task >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.20.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Release 1.20 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-4935: - Affects Version/s: (was: avatica-1.20.0) > Avatica standalone-server shades log4j without relocation > - > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
[ https://issues.apache.org/jira/browse/CALCITE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-4935: - Fix Version/s: avatica-1.20.0 > Avatica standalone-server shades log4j without relocation > - > > Key: CALCITE-4935 > URL: https://issues.apache.org/jira/browse/CALCITE-4935 > Project: Calcite > Issue Type: Bug > Components: avatica >Affects Versions: avatica-1.20.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > > The issue has been found during the vote for avatica-1.20.0 RC0. > The standalone-server jar in the [staged maven > repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] > contains log4j2 classes but they are not relocated. > In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all > relocated to avoid classpath problems with other libraries/apps potentially > using another log4j2 version. > It seems that relocation was dropped in possibly unintenionally in > CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-4936) Using LogicalCalc in ProjectCalcMergeRule and FilterCalcMergeRule
[
https://issues.apache.org/jira/browse/CALCITE-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Gramin updated CALCITE-4936:
---
Description:
I noticed that rules ProjectCalcMergeRule and FilterCalcMergeRule strictly
dependent on LogicalCalc class (e.g. casting call.rel to LogicalCalc, using
LogicalCalc.create method and etc). I suggest making them more generalized
(like CalcMergeRule) and use only Project, Filter and Calc interfaces, which
will expand the range of their applying.
Concrete:
1. In FilterCalcMergeRule get rid of casting to LogicalCalc and LogicalFilter:
{code:java}
@Override public void onMatch(RelOptRuleCall call) {
final Filter filter = call.rel(0);
final Calc calc = call.rel(1);{code}
2. In FilterCalcMergeRule and FilterCalcMergeRule replace LogicalCalc.create
with calc.copy:
{code:java}
final Calc newCalc = calc.copy(calc.getTraitSet(), calc.getInput(),
mergedProgram);{code}
3. In ProjectCalcMergeRule replace the code:
{code:java}
if (RexOver.containsOver(program)) {
LogicalCalc projectAsCalc = LogicalCalc.create(calc, program);
call.transformTo(projectAsCalc);
return;
}{code}
with a simple one:
{code:java}
if (RexOver.containsOver(program)) {
return;
}{code}
because special rule ProjectToCalcRule convert LogicalProject to LogicalCalc.
was:
I noticed that rules ProjectCalcMergeRule and FilterCalcMergeRule
strictly dependent on LogicalCalc class (e.g. casting call.rel to
LogicalCalc, using LogicalCalc.create method and etc). I suggest
making them more generalized (like CalcMergeRule) and use only
Project, Filter and Calc interfaces, which will expand the range of
their applying.
Concrete:
1. In FilterCalcMergeRule get rid of casting to LogicalCalc and LogicalFilter:
{code:java}
@Override public void onMatch(RelOptRuleCall call) {
final Filter filter = call.rel(0);
final Calc calc = call.rel(1);{code}
2. In FilterCalcMergeRule and FilterCalcMergeRule replace
LogicalCalc.create with calc.copy:
{code:java}
final Calc newCalc = calc.copy(calc.getTraitSet(), calc.getInput(),
mergedProgram);{code}
3. In ProjectCalcMergeRule replace the code:
{code:java}
if (RexOver.containsOver(program)) {
LogicalCalc projectAsCalc = LogicalCalc.create(calc, program);
call.transformTo(projectAsCalc);
return;
}{code}
with a simple one:
{code:java}
if (RexOver.containsOver(program)) {
return;
}{code}
because special rule ProjectToCalcRule convert LogicalProject to LogicalCalc.
> Using LogicalCalc in ProjectCalcMergeRule and FilterCalcMergeRule
> -
>
> Key: CALCITE-4936
> URL: https://issues.apache.org/jira/browse/CALCITE-4936
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.28.0
>Reporter: Maksim Gramin
>Priority: Major
>
> I noticed that rules ProjectCalcMergeRule and FilterCalcMergeRule strictly
> dependent on LogicalCalc class (e.g. casting call.rel to LogicalCalc, using
> LogicalCalc.create method and etc). I suggest making them more generalized
> (like CalcMergeRule) and use only Project, Filter and Calc interfaces, which
> will expand the range of their applying.
> Concrete:
> 1. In FilterCalcMergeRule get rid of casting to LogicalCalc and LogicalFilter:
> {code:java}
> @Override public void onMatch(RelOptRuleCall call) {
> final Filter filter = call.rel(0);
> final Calc calc = call.rel(1);{code}
>
> 2. In FilterCalcMergeRule and FilterCalcMergeRule replace LogicalCalc.create
> with calc.copy:
> {code:java}
> final Calc newCalc = calc.copy(calc.getTraitSet(), calc.getInput(),
> mergedProgram);{code}
>
> 3. In ProjectCalcMergeRule replace the code:
> {code:java}
> if (RexOver.containsOver(program)) {
> LogicalCalc projectAsCalc = LogicalCalc.create(calc, program);
> call.transformTo(projectAsCalc);
> return;
> }{code}
> with a simple one:
> {code:java}
> if (RexOver.containsOver(program)) {
> return;
> }{code}
> because special rule ProjectToCalcRule convert LogicalProject to LogicalCalc.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CALCITE-4936) Using LogicalCalc in ProjectCalcMergeRule and FilterCalcMergeRule
Maksim Gramin created CALCITE-4936:
--
Summary: Using LogicalCalc in ProjectCalcMergeRule and
FilterCalcMergeRule
Key: CALCITE-4936
URL: https://issues.apache.org/jira/browse/CALCITE-4936
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.28.0
Reporter: Maksim Gramin
I noticed that rules ProjectCalcMergeRule and FilterCalcMergeRule
strictly dependent on LogicalCalc class (e.g. casting call.rel to
LogicalCalc, using LogicalCalc.create method and etc). I suggest
making them more generalized (like CalcMergeRule) and use only
Project, Filter and Calc interfaces, which will expand the range of
their applying.
Concrete:
1. In FilterCalcMergeRule get rid of casting to LogicalCalc and LogicalFilter:
{code:java}
@Override public void onMatch(RelOptRuleCall call) {
final Filter filter = call.rel(0);
final Calc calc = call.rel(1);{code}
2. In FilterCalcMergeRule and FilterCalcMergeRule replace
LogicalCalc.create with calc.copy:
{code:java}
final Calc newCalc = calc.copy(calc.getTraitSet(), calc.getInput(),
mergedProgram);{code}
3. In ProjectCalcMergeRule replace the code:
{code:java}
if (RexOver.containsOver(program)) {
LogicalCalc projectAsCalc = LogicalCalc.create(calc, program);
call.transformTo(projectAsCalc);
return;
}{code}
with a simple one:
{code:java}
if (RexOver.containsOver(program)) {
return;
}{code}
because special rule ProjectToCalcRule convert LogicalProject to LogicalCalc.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CALCITE-4935) Avatica standalone-server shades log4j without relocation
Stamatis Zampetakis created CALCITE-4935: Summary: Avatica standalone-server shades log4j without relocation Key: CALCITE-4935 URL: https://issues.apache.org/jira/browse/CALCITE-4935 Project: Calcite Issue Type: Bug Components: avatica Affects Versions: avatica-1.20.0 Reporter: Stamatis Zampetakis Assignee: Stamatis Zampetakis The issue has been found during the vote for avatica-1.20.0 RC0. The standalone-server jar in the [staged maven repository|https://repository.apache.org/content/repositories/orgapachecalcite-1122/org/apache/calcite/avatica/avatica-standalone-server/1.20.0/avatica-standalone-server-1.20.0.jar] contains log4j2 classes but they are not relocated. In previous, Avatica versions (e.g., avatica-1.19.0), log4j classes were all relocated to avoid classpath problems with other libraries/apps potentially using another log4j2 version. It seems that relocation was dropped in possibly unintenionally in CALCITE-4152. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-4933) Release Avatica 1.20.0
[ https://issues.apache.org/jira/browse/CALCITE-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-4933: - Summary: Release Avatica 1.20.0 (was: Release avatica 1.20) > Release Avatica 1.20.0 > -- > > Key: CALCITE-4933 > URL: https://issues.apache.org/jira/browse/CALCITE-4933 > Project: Calcite > Issue Type: Task >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: avatica-1.20.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Release 1.20 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4934) Deploy snapshot releases to Apache snapshot repo
[ https://issues.apache.org/jira/browse/CALCITE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457707#comment-17457707 ] Jacques Nadeau commented on CALCITE-4934: - This seems like it is working but we need to be able to access the GitHub secrets for deployment. Filed INFRA-22601 to accomplish that. > Deploy snapshot releases to Apache snapshot repo > > > Key: CALCITE-4934 > URL: https://issues.apache.org/jira/browse/CALCITE-4934 > Project: Calcite > Issue Type: Improvement >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau >Priority: Major > > It would be helpful to be able to test out snapshot builds of Calcite without > having to build locally. It seems like CALCITE-351 originally implemented > this but it hasn't been happening for many years. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4934) Deploy snapshot releases to Apache snapshot repo
[ https://issues.apache.org/jira/browse/CALCITE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457703#comment-17457703 ] Jacques Nadeau commented on CALCITE-4934: - To test this, I'm going to use a build-test branch on Apache. I plan to delete the branch after testing is complete. > Deploy snapshot releases to Apache snapshot repo > > > Key: CALCITE-4934 > URL: https://issues.apache.org/jira/browse/CALCITE-4934 > Project: Calcite > Issue Type: Improvement >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau >Priority: Major > > It would be helpful to be able to test out snapshot builds of Calcite without > having to build locally. It seems like CALCITE-351 originally implemented > this but it hasn't been happening for many years. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CALCITE-4934) Deploy snapshot releases to Apache snapshot repo
Jacques Nadeau created CALCITE-4934: --- Summary: Deploy snapshot releases to Apache snapshot repo Key: CALCITE-4934 URL: https://issues.apache.org/jira/browse/CALCITE-4934 Project: Calcite Issue Type: Improvement Reporter: Jacques Nadeau Assignee: Jacques Nadeau It would be helpful to be able to test out snapshot builds of Calcite without having to build locally. It seems like CALCITE-351 originally implemented this but it hasn't been happening for many years. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CALCITE-4933) Release avatica 1.20
Josh Elser created CALCITE-4933: --- Summary: Release avatica 1.20 Key: CALCITE-4933 URL: https://issues.apache.org/jira/browse/CALCITE-4933 Project: Calcite Issue Type: Task Reporter: Josh Elser Assignee: Josh Elser Fix For: avatica-1.20.0 Release 1.20 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CALCITE-4928) Decouple Janino from RelMetadataQuery
[ https://issues.apache.org/jira/browse/CALCITE-4928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Nadeau resolved CALCITE-4928. - Fix Version/s: 1.29.0 Resolution: Fixed Merged in [f3c09365c2eecbb5198d9acbef638f76053a49a9|https://github.com/apache/calcite/commit/f3c09365c2eecbb5198d9acbef638f76053a49a9] > Decouple Janino from RelMetadataQuery > - > > Key: CALCITE-4928 > URL: https://issues.apache.org/jira/browse/CALCITE-4928 > Project: Calcite > Issue Type: Improvement >Reporter: Jacques Nadeau >Assignee: Jacques Nadeau >Priority: Major > Labels: pull-request-available > Fix For: 1.29.0 > > Time Spent: 1h > Remaining Estimate: 0h > > * After discussion in CALCITE-4879 and CALCITE-4914, lets create a minimally > invasive version of CALCITE-4539 that allows decoupling of Janino. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-1244) `offset` is ignored in FetchRequest
[
https://issues.apache.org/jira/browse/CALCITE-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1244:
Fix Version/s: avatica-1.21.0
(was: avatica-1.20.0)
> `offset` is ignored in FetchRequest
> ---
>
> Key: CALCITE-1244
> URL: https://issues.apache.org/jira/browse/CALCITE-1244
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Josh Elser
>Priority: Major
> Fix For: avatica-1.21.0
>
>
> In looking into some issues reported by [~onpduo], we both noticed that
> {{FetchRequest.offset}} is never actually used by the server.
> We should make sure the semantics on this value are clear (is it an offset
> from the beginning of the ResultSet or the current position of the
> ResultSet?) and make sure it is used.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[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 ] Josh Elser updated CALCITE-839: --- Fix Version/s: avatica-1.21.0 (was: avatica-1.20.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.21.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 (v8.20.1#820001)
[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 ] Josh Elser updated CALCITE-1242: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.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.21.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 (v8.20.1#820001)
[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
]
Josh Elser updated CALCITE-1811:
Fix Version/s: avatica-1.21.0
(was: avatica-1.20.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.21.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
(v8.20.1#820001)
[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 ] Josh Elser updated CALCITE-1385: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.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.21.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 (v8.20.1#820001)
[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 ] Josh Elser updated CALCITE-1928: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.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.21.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 (v8.20.1#820001)
[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 ] Josh Elser updated CALCITE-1316: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.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.21.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 (v8.20.1#820001)
[jira] [Updated] (CALCITE-3162) Reading Arrays from Calcite through JdbcMeta generates AvaticaSqlException
[
https://issues.apache.org/jira/browse/CALCITE-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-3162:
Fix Version/s: avatica-1.21.0
(was: avatica-1.20.0)
> Reading Arrays from Calcite through JdbcMeta generates AvaticaSqlException
> --
>
> Key: CALCITE-3162
> URL: https://issues.apache.org/jira/browse/CALCITE-3162
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.15.0
> Environment: Tested on OS X 10.14.5, OpenJDK Runtime Environment
> Zulu11.29+3-CA (build 11.0.2+7-LTS)
> Issue occurs with both Apache Calcite 1.19.0 & 1.20.0.
>Reporter: Ralph Gasser
>Priority: Major
> Labels: pull-request-available
> Fix For: avatica-1.21.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm trying to use _Apache Calcite_ as SQL Parser and Query Planner for a
> custom data store and in addition, I'm using _Apache Avatica_ to expose the
> entire functionality via JDBC for an arbitrary, potential remote client to
> use.
> We're working a lot with Array types, since we're using our backend to store
> high-dimensional vectors. However, it seems that currently, Apache Avatica
> has troubles handling such arrays.
> Take the following test-case that reproduces the problem pretty well.
> {code:java}
> @Test
> public void test() throws Exception {
> HttpServer server = null;
> try {
> Class.forName("org.apache.calcite.jdbc.Driver");
> server = new HttpServer.Builder<>()
> .withHandler(new LocalService(new JdbcMeta("jdbc:calcite:",
> newProperties())),Driver.Serialization.PROTOBUF)
> .withPort(1234)
> .build();
> server.start();
> final Connection connection =
> DriverManager.getConnection("jdbc:avatica:remote:serialization=protobuf;url=http://127.0.0.1:1234;);
> final Statement stmt = connection.createStatement();
> final ResultSet resultSet = stmt.executeQuery("select ARRAY[1.0, 1.0,
> 3.0, 2.0]");
> resultSet.next();
> resultSet.getArray(1);
> } catch (Exception e) {
> System.out.println(e.getMessage());
> } finally {
> if (server != null) {
>server.stop();
> }
> }
> }
> {code}
> Executing the statement will throw an AvaticaSqlException:
> {code:java}
> org.apache.calcite.avatica.AvaticaSqlException: Error -1 (0) : Error
> while executing SQL "select ARRAY[1.0, 1.0, 3.0, 2.0]": Remote driver error:
> RuntimeException: java.sql.SQLException: invalid column ordinal: 2 ->
> SQLException: invalid column ordinal: 2
> {code}
> The culprit seems to be the _org.apache.calcite.avatica.jdbc.JdbcResultSet_
> class. More specifically, the _JdbcResultSet#extractUsingResultSet()_ method.
> I am actually testing a potential fix but first I wanted to make sure, that
> there is nothing wrong with the way I'm using the two components.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-2983) Add Avatica compatibility page for TLS and IBM Java
[ https://issues.apache.org/jira/browse/CALCITE-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated CALCITE-2983: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.0) > Add Avatica compatibility page for TLS and IBM Java > --- > > Key: CALCITE-2983 > URL: https://issues.apache.org/jira/browse/CALCITE-2983 > Project: Calcite > Issue Type: Task > Components: avatica, site >Reporter: Kevin Risden >Priority: Major > Fix For: avatica-1.21.0 > > > With the Jetty upgrade in CALCITE-2972, there are some compatibility issues > between TLS support and IBM Java. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[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 ] Josh Elser updated CALCITE-1308: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.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.21.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 (v8.20.1#820001)
[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
]
Josh Elser updated CALCITE-1352:
Fix Version/s: avatica-1.21.0
(was: avatica-1.20.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.21.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
(v8.20.1#820001)
[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
]
Josh Elser updated CALCITE-1341:
Fix Version/s: avatica-1.21.0
(was: avatica-1.20.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.21.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
(v8.20.1#820001)
[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 ] Josh Elser updated CALCITE-1318: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.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.21.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 (v8.20.1#820001)
[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
]
Josh Elser updated CALCITE-1164:
Fix Version/s: avatica-1.21.0
(was: avatica-1.20.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.21.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
(v8.20.1#820001)
[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 ] Josh Elser updated CALCITE-1350: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.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.21.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 (v8.20.1#820001)
[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 ] Josh Elser updated CALCITE-1286: Fix Version/s: avatica-1.21.0 (was: avatica-1.20.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.21.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 (v8.20.1#820001)
[jira] [Updated] (CALCITE-4905) JdbcCalc does not extend Calc
[
https://issues.apache.org/jira/browse/CALCITE-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Gini updated CALCITE-4905:
Labels: (was: pull-request-available)
> JdbcCalc does not extend Calc
> -
>
> Key: CALCITE-4905
> URL: https://issues.apache.org/jira/browse/CALCITE-4905
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.28.0
>Reporter: Francesco Gini
>Assignee: Francesco Gini
>Priority: Major
> Attachments: test_with_failing_JdbcCalc_conversion.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{JdbcCalc}} class does not implement Calc. Failing to do that means that
> {{RelToSqlConverter}} cannot translate a plan with {{JdbcCalc}} into sql
> because {{RelToSqlConverter}} expects
> {code:java}
> public Result visit(Calc e){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CALCITE-4931) Upgrade SLF4J binding to Log4j2 version 2.15.0
[ https://issues.apache.org/jira/browse/CALCITE-4931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved CALCITE-4931. - Resolution: Fixed > Upgrade SLF4J binding to Log4j2 version 2.15.0 > -- > > Key: CALCITE-4931 > URL: https://issues.apache.org/jira/browse/CALCITE-4931 > Project: Calcite > Issue Type: Task > Components: avatica >Affects Versions: avatica-1.19.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Fix For: avatica-1.20.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Log4j (binding) is used for testing purposes in various modules and for > production code (shaded) in standalone-server and tck modules. > The slf4j-log4j12 dependency (currently in use) relies on Log4j 1.x which has > reached [end of > life|https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces] > in 2015. > The goal of this issue is to replace slf4j-log4j12 with log4j-slf4j-impl > binding which uses Log4j2 and take the latest version. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-4905) JdbcCalc does not extend Calc
[
https://issues.apache.org/jira/browse/CALCITE-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4905:
Labels: pull-request-available (was: )
> JdbcCalc does not extend Calc
> -
>
> Key: CALCITE-4905
> URL: https://issues.apache.org/jira/browse/CALCITE-4905
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.28.0
>Reporter: Francesco Gini
>Assignee: Francesco Gini
>Priority: Major
> Labels: pull-request-available
> Attachments: test_with_failing_JdbcCalc_conversion.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{JdbcCalc}} class does not implement Calc. Failing to do that means that
> {{RelToSqlConverter}} cannot translate a plan with {{JdbcCalc}} into sql
> because {{RelToSqlConverter}} expects
> {code:java}
> public Result visit(Calc e){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4905) JdbcCalc does not extend Calc
[
https://issues.apache.org/jira/browse/CALCITE-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Gini updated CALCITE-4905:
Labels: (was: pull-request-available)
> JdbcCalc does not extend Calc
> -
>
> Key: CALCITE-4905
> URL: https://issues.apache.org/jira/browse/CALCITE-4905
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.28.0
>Reporter: Francesco Gini
>Assignee: Francesco Gini
>Priority: Major
> Attachments: test_with_failing_JdbcCalc_conversion.patch
>
>
> {{JdbcCalc}} class does not implement Calc. Failing to do that means that
> {{RelToSqlConverter}} cannot translate a plan with {{JdbcCalc}} into sql
> because {{RelToSqlConverter}} expects
> {code:java}
> public Result visit(Calc e){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CALCITE-4905) JdbcCalc does not extend Calc
[
https://issues.apache.org/jira/browse/CALCITE-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Gini resolved CALCITE-4905.
-
Resolution: Won't Fix
Resolving the issue because, as per discussion in the ticket, deprecating
{{JdbcCalc}} is the way to go https://issues.apache.org/jira/browse/CALCITE-4932
> JdbcCalc does not extend Calc
> -
>
> Key: CALCITE-4905
> URL: https://issues.apache.org/jira/browse/CALCITE-4905
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.28.0
>Reporter: Francesco Gini
>Assignee: Francesco Gini
>Priority: Major
> Labels: pull-request-available
> Attachments: test_with_failing_JdbcCalc_conversion.patch
>
>
> {{JdbcCalc}} class does not implement Calc. Failing to do that means that
> {{RelToSqlConverter}} cannot translate a plan with {{JdbcCalc}} into sql
> because {{RelToSqlConverter}} expects
> {code:java}
> public Result visit(Calc e){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CALCITE-4932) Deprecate JdbcCalc and JdbcCalcRule
Francesco Gini created CALCITE-4932:
---
Summary: Deprecate JdbcCalc and JdbcCalcRule
Key: CALCITE-4932
URL: https://issues.apache.org/jira/browse/CALCITE-4932
Project: Calcite
Issue Type: Task
Components: jdbc-adapter
Affects Versions: 1.28.0
Reporter: Francesco Gini
The jdbc adapter includes a node and rule for {{Calc}} ( {{{}JdbcCal{}}}c a
{{JdbcCalcRule}} ). {{Calc}} is an operation that is introduced only later in
the planner to optimise certain code generation and it is not needed for the
jdbc adapter.
As it stands the rule {{JdbcCalcRule}} is never triggered because the {{Jdbc}}
convention rules are applied before the {{Calc}} node is introduced in the
plan. However, if a user try to use a custom rule set they might end up with a
{{JdbcCalc}} which introduces problems like the one described in
https://issues.apache.org/jira/browse/CALCITE-4905 .
Because {{JdbcCalc}} is not an optimisation needed for jdbc anyway we should
deprecate {{JdbcCalc}} and its respective rule {{{}JdbcCalcRule{}}}. The rule
should also be removed from {{JdbcRules.rules}}
See ticket https://issues.apache.org/jira/browse/CALCITE-4905 for a discussion
around deprecating {{JdbcCalc}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
