[jira] [Commented] (CALCITE-6357) Calcite enforces select arguments count to be same as row schema fields which causes aliases to be ignored

[Kenneth Knowles (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836303#comment-17836303
 ] 

Kenneth Knowles commented on CALCITE-6357:
--

I'm still stuck on the idea that if I write "select x as col1, y as col2 from 
aTableWithAHundredColumns" it could be valid to return a table with columns x 
and y. I would be shocked if there exists an RDMS in the world that fails to 
give output with columns col1 and col2. So I just mean to ask how we (Beam) can 
invoke calcite to achieve that. I'm sure it works, since of course all the 
other users of Calcite haven't hit this.

> Calcite enforces select arguments count to be same as row schema fields which 
> causes aliases to be ignored
> --
>
> Key: CALCITE-6357
> URL: https://issues.apache.org/jira/browse/CALCITE-6357
> Project: Calcite
>  Issue Type: Bug
>Reporter: Brachi Packter
>Priority: Major
>
> Calcite RelBuilder.ProjectNamed checks if row size in the select is identical 
> to schema fields, if no, it creates a project with fields as they appear in 
> the select , meaning if they have aliases, they are returning with their 
> aliases.
> Here, it checks if they are identical:
> https://github.com/apache/calcite/blob/f14cf4c32b9079984a988bbad40230aa6a59b127/core/src/main/java/org/apache/calcite/tools/RelBuilder.java#L2063
> using RexUtil.isIdentity method:
> ```
>  public static boolean isIdentity(List exps,
>   RelDataType inputRowType) {
> return inputRowType.getFieldCount() == exps.size()
> && containIdentity(exps, inputRowType, Litmus.IGNORE);
>   }
> ```
> This is the problematic part `inputRowType.getFieldCount() == exps.size()`
> If they are identical, and return with their aliases, it is ignored in the 
> "rename" method later on
> https://github.com/apache/calcite/blob/f14cf4c32b9079984a988bbad40230aa6a59b127/core/src/main/java/org/apache/calcite/tools/RelBuilder.java#L2125
> and alias is skipped
> https://github.com/apache/calcite/blob/f14cf4c32b9079984a988bbad40230aa6a59b127/core/src/main/java/org/apache/calcite/tools/RelBuilder.java#L2137
> This doesn't impact calcite queries, but in Apache Beam they are doing some 
> optimization on top of it, 
> https://github.com/apache/beam/blob/master/sdks/java/extensions/sql/src/main/java/org/apache/beam/sdk/extensions/sql/impl/rule/BeamAggregateProjectMergeRule.java
> which causes aliases to be ignored, and data is returning suddenly without 
> correct column field.
> I believe the isIdentity check can causes more issues if not fixed, we need 
> to understand why is it enforced? isn't it valid to have different size of 
> fields in select from what we have in the schema?
> In our case we have a one big row and we run on it different queries, each 
> with different fields in the select.
> Beam issue 
> https://github.com/apache/beam/issues/30498 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CALCITE-6357) Calcite enforces select arguments count to be same as row schema fields which causes aliases to be ignored

[Kenneth Knowles (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835868#comment-17835868
 ] 

Kenneth Knowles commented on CALCITE-6357:
--

[~julianhyde] - are we "holding it wrong"? Can you help us understand how?

I presume you would agree that names of output columns is as much part of data 
integrity as the values. So in BeamAggregateProjectMergeRule are we somehow 
making Calcite think this is not the output column?

It does seem that our rule is the delta that causes the problem. Calcite 
without that rule seems to do the right thing. The rule does one thing: runs 
the normal AggregateProjectMergeRule only when the underlying connector does 
*not* support pushdown.

In the queries that hit this bug, we know that the connector does *not* support 
pushdown, so the original behavior should be maintained.

> Calcite enforces select arguments count to be same as row schema fields which 
> causes aliases to be ignored
> --
>
> Key: CALCITE-6357
> URL: https://issues.apache.org/jira/browse/CALCITE-6357
> Project: Calcite
>  Issue Type: Bug
>Reporter: Brachi Packter
>Priority: Major
>
> Calcite RelBuilder.ProjectNamed checks if row size in the select is identical 
> to schema fields, if no, it creates a project with fields as they appear in 
> the select , meaning if they have aliases, they are returning with their 
> aliases.
> Here, it checks if they are identical:
> https://github.com/apache/calcite/blob/f14cf4c32b9079984a988bbad40230aa6a59b127/core/src/main/java/org/apache/calcite/tools/RelBuilder.java#L2063
> using RexUtil.isIdentity method:
> ```
>  public static boolean isIdentity(List exps,
>   RelDataType inputRowType) {
> return inputRowType.getFieldCount() == exps.size()
> && containIdentity(exps, inputRowType, Litmus.IGNORE);
>   }
> ```
> This is the problematic part `inputRowType.getFieldCount() == exps.size()`
> If they are identical, and return with their aliases, it is ignored in the 
> "rename" method later on
> https://github.com/apache/calcite/blob/f14cf4c32b9079984a988bbad40230aa6a59b127/core/src/main/java/org/apache/calcite/tools/RelBuilder.java#L2125
> and alias is skipped
> https://github.com/apache/calcite/blob/f14cf4c32b9079984a988bbad40230aa6a59b127/core/src/main/java/org/apache/calcite/tools/RelBuilder.java#L2137
> This doesn't impact calcite queries, but in Apache Beam they are doing some 
> optimization on top of it, 
> https://github.com/apache/beam/blob/master/sdks/java/extensions/sql/src/main/java/org/apache/beam/sdk/extensions/sql/impl/rule/BeamAggregateProjectMergeRule.java
> which causes aliases to be ignored, and data is returning suddenly without 
> correct column field.
> I believe the isIdentity check can causes more issues if not fixed, we need 
> to understand why is it enforced? isn't it valid to have different size of 
> fields in select from what we have in the schema?
> In our case we have a one big row and we run on it different queries, each 
> with different fields in the select.
> Beam issue 
> https://github.com/apache/beam/issues/30498 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (CALCITE-2634) Query with WITH and SOME parses but fails to convert to rel

[Kenneth Knowles (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345560#comment-17345560
 ] 

Kenneth Knowles commented on CALCITE-2634:
--

Unassigning because I won't have time to dig into this and fix our invocation 
either. CC [~apilloud] who at this point knows far more about Beam SQL 
implementation than I do.

> Query with WITH and SOME parses but fails to convert to rel
> ---
>
> Key: CALCITE-2634
> URL: https://issues.apache.org/jira/browse/CALCITE-2634
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Kenneth Knowles
>Priority: Major
>
> The following query parses but fails to convert to logical rels:
> {code:sql}
> WITH BidCount (auction, num, hopstart) AS (
>   SELECT
> Bid.auction,
> count(*),
> HOP_START(Bid.dateTime, INTERVAL '1' SECOND, INTERVAL '60' SECOND)
>   FROM Bid
>   GROUP BY
> Bid.auction,
> HOP(Bid.dateTime, INTERVAL '1' SECOND, INTERVAL '60' SECOND)
>   )
> SELECT HotAuction.auction, HotAuction.num, HotAuction.hopstart
> FROM BidCount as HotAuction
> WHERE HotAuction.num >= ALL (
>   SELECT num FROM BidCount
>   WHERE HotAuction.hopstart = BidCount.hopstart)
> {code}
> The validated SQL node pretty prints like so:
> {code:sql}
> WITH `BidCount` (`auction`, `num`, `hopstart`) AS (SELECT `Bid`.`auction`, 
> COUNT(*), HOP_START(`Bid`.`dateTime`, INTERVAL '5' SECOND, INTERVAL '10' 
> SECOND)
> FROM `beam`.`Bid` AS `Bid`
> GROUP BY `Bid`.`auction`, HOP(`Bid`.`dateTime`, INTERVAL '5' SECOND, INTERVAL 
> '10' SECOND)) (SELECT `HotAuction`.`auction`, `HotAuction`.`num`, 
> `HotAuction`.`hopstart`
> FROM `BidCount` AS `HotAuction`
> WHERE `HotAuction`.`num` >= ALL (SELECT `BidCount`.`num`
> FROM `BidCount` AS `BidCount`
> WHERE `HotAuction`.`hopstart` = `BidCount`.`hopstart`))
> {code}
> The stack trace is here:
> {code:java}
> java.lang.ClassCastException: org.apache.calcite.rel.logical.LogicalFilter 
> cannot be cast to org.apache.calcite.rel.core.Join
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.translateIn(SqlToRelConverter.java:1242)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.substituteSubQuery(SqlToRelConverter.java:1129)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.replaceSubQueries(SqlToRelConverter.java:997)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:964)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:643)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:621)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3051)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWith(SqlToRelConverter.java:3891)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3065)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
>   at oorg.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:235)
> {code}
> For context, this is working with Beam SQL but the failure occurs before any 
> Beam-related code is reached: [https://github.com/apache/beam/pull/6757/files]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (CALCITE-2634) Query with WITH and SOME parses but fails to convert to rel

[Kenneth Knowles (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345560#comment-17345560
 ] 

Kenneth Knowles edited comment on CALCITE-2634 at 5/15/21, 6:04 PM:


Unassigning because I won't have time to dig into this and fix our invocation 
either. CC [~apilloud] who knows far more about Beam SQL implementation than I 
do.


was (Author: kenn):
Unassigning because I won't have time to dig into this and fix our invocation 
either. CC [~apilloud] who at this point knows far more about Beam SQL 
implementation than I do.

> Query with WITH and SOME parses but fails to convert to rel
> ---
>
> Key: CALCITE-2634
> URL: https://issues.apache.org/jira/browse/CALCITE-2634
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Kenneth Knowles
>Priority: Major
>
> The following query parses but fails to convert to logical rels:
> {code:sql}
> WITH BidCount (auction, num, hopstart) AS (
>   SELECT
> Bid.auction,
> count(*),
> HOP_START(Bid.dateTime, INTERVAL '1' SECOND, INTERVAL '60' SECOND)
>   FROM Bid
>   GROUP BY
> Bid.auction,
> HOP(Bid.dateTime, INTERVAL '1' SECOND, INTERVAL '60' SECOND)
>   )
> SELECT HotAuction.auction, HotAuction.num, HotAuction.hopstart
> FROM BidCount as HotAuction
> WHERE HotAuction.num >= ALL (
>   SELECT num FROM BidCount
>   WHERE HotAuction.hopstart = BidCount.hopstart)
> {code}
> The validated SQL node pretty prints like so:
> {code:sql}
> WITH `BidCount` (`auction`, `num`, `hopstart`) AS (SELECT `Bid`.`auction`, 
> COUNT(*), HOP_START(`Bid`.`dateTime`, INTERVAL '5' SECOND, INTERVAL '10' 
> SECOND)
> FROM `beam`.`Bid` AS `Bid`
> GROUP BY `Bid`.`auction`, HOP(`Bid`.`dateTime`, INTERVAL '5' SECOND, INTERVAL 
> '10' SECOND)) (SELECT `HotAuction`.`auction`, `HotAuction`.`num`, 
> `HotAuction`.`hopstart`
> FROM `BidCount` AS `HotAuction`
> WHERE `HotAuction`.`num` >= ALL (SELECT `BidCount`.`num`
> FROM `BidCount` AS `BidCount`
> WHERE `HotAuction`.`hopstart` = `BidCount`.`hopstart`))
> {code}
> The stack trace is here:
> {code:java}
> java.lang.ClassCastException: org.apache.calcite.rel.logical.LogicalFilter 
> cannot be cast to org.apache.calcite.rel.core.Join
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.translateIn(SqlToRelConverter.java:1242)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.substituteSubQuery(SqlToRelConverter.java:1129)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.replaceSubQueries(SqlToRelConverter.java:997)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:964)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:643)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:621)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3051)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWith(SqlToRelConverter.java:3891)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3065)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
>   at oorg.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:235)
> {code}
> For context, this is working with Beam SQL but the failure occurs before any 
> Beam-related code is reached: [https://github.com/apache/beam/pull/6757/files]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (CALCITE-2634) Query with WITH and SOME parses but fails to convert to rel

[Kenneth Knowles (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kenneth Knowles reassigned CALCITE-2634:


Assignee: (was: Kenneth Knowles)

> Query with WITH and SOME parses but fails to convert to rel
> ---
>
> Key: CALCITE-2634
> URL: https://issues.apache.org/jira/browse/CALCITE-2634
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Kenneth Knowles
>Priority: Major
>
> The following query parses but fails to convert to logical rels:
> {code:sql}
> WITH BidCount (auction, num, hopstart) AS (
>   SELECT
> Bid.auction,
> count(*),
> HOP_START(Bid.dateTime, INTERVAL '1' SECOND, INTERVAL '60' SECOND)
>   FROM Bid
>   GROUP BY
> Bid.auction,
> HOP(Bid.dateTime, INTERVAL '1' SECOND, INTERVAL '60' SECOND)
>   )
> SELECT HotAuction.auction, HotAuction.num, HotAuction.hopstart
> FROM BidCount as HotAuction
> WHERE HotAuction.num >= ALL (
>   SELECT num FROM BidCount
>   WHERE HotAuction.hopstart = BidCount.hopstart)
> {code}
> The validated SQL node pretty prints like so:
> {code:sql}
> WITH `BidCount` (`auction`, `num`, `hopstart`) AS (SELECT `Bid`.`auction`, 
> COUNT(*), HOP_START(`Bid`.`dateTime`, INTERVAL '5' SECOND, INTERVAL '10' 
> SECOND)
> FROM `beam`.`Bid` AS `Bid`
> GROUP BY `Bid`.`auction`, HOP(`Bid`.`dateTime`, INTERVAL '5' SECOND, INTERVAL 
> '10' SECOND)) (SELECT `HotAuction`.`auction`, `HotAuction`.`num`, 
> `HotAuction`.`hopstart`
> FROM `BidCount` AS `HotAuction`
> WHERE `HotAuction`.`num` >= ALL (SELECT `BidCount`.`num`
> FROM `BidCount` AS `BidCount`
> WHERE `HotAuction`.`hopstart` = `BidCount`.`hopstart`))
> {code}
> The stack trace is here:
> {code:java}
> java.lang.ClassCastException: org.apache.calcite.rel.logical.LogicalFilter 
> cannot be cast to org.apache.calcite.rel.core.Join
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.translateIn(SqlToRelConverter.java:1242)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.substituteSubQuery(SqlToRelConverter.java:1129)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.replaceSubQueries(SqlToRelConverter.java:997)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:964)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:643)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:621)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3051)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWith(SqlToRelConverter.java:3891)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3065)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
>   at oorg.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:235)
> {code}
> For context, this is working with Beam SQL but the failure occurs before any 
> Beam-related code is reached: [https://github.com/apache/beam/pull/6757/files]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CALCITE-2394) Avatica applies calendar offset to timestamps when they should remain unchanged

[Kenneth Knowles (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345559#comment-17345559
 ] 

Kenneth Knowles commented on CALCITE-2394:
--

Unassigning to be realistic about the fact that I am not working on this and 
will not have time to do so.

> Avatica applies calendar offset to timestamps when they should remain 
> unchanged
> ---
>
> Key: CALCITE-2394
> URL: https://issues.apache.org/jira/browse/CALCITE-2394
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Kenneth Knowles
>Priority: Major
>
> This code converts a millis-since-epoch value to a timestamp in three 
> different accessors:
> {code}
> class AbstractCursor {
>   ...
>   static Timestamp longToTimestamp(long v, Calendar calendar) {
> if (calendar != null) {
>   v -= calendar.getTimeZone().getOffset(v);
> }
> return new Timestamp(v);
>   }
> }
> {code}
> But {{new Timestamp(millis)}} always accepts millis-since-epoch in GMT.
> The use in {{DateFromNumberAccessor}} is probably OK: it fabricates 
> millis-since-epoch from a date, so applying the offset is appropriate to hit 
> midnight in that locale.
> But both {{TimeFromNumberAccessor}} and {{TimestampFromNumberAccessor}} 
> should leave the millis absolute.
> This manifests as timestamp actual values being shifted by the current locale 
> (in addition to later display adjustments).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (CALCITE-2394) Avatica applies calendar offset to timestamps when they should remain unchanged

[Kenneth Knowles (Jira)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kenneth Knowles reassigned CALCITE-2394:


Assignee: (was: Kenneth Knowles)

> Avatica applies calendar offset to timestamps when they should remain 
> unchanged
> ---
>
> Key: CALCITE-2394
> URL: https://issues.apache.org/jira/browse/CALCITE-2394
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Kenneth Knowles
>Priority: Major
>
> This code converts a millis-since-epoch value to a timestamp in three 
> different accessors:
> {code}
> class AbstractCursor {
>   ...
>   static Timestamp longToTimestamp(long v, Calendar calendar) {
> if (calendar != null) {
>   v -= calendar.getTimeZone().getOffset(v);
> }
> return new Timestamp(v);
>   }
> }
> {code}
> But {{new Timestamp(millis)}} always accepts millis-since-epoch in GMT.
> The use in {{DateFromNumberAccessor}} is probably OK: it fabricates 
> millis-since-epoch from a date, so applying the offset is appropriate to hit 
> midnight in that locale.
> But both {{TimeFromNumberAccessor}} and {{TimestampFromNumberAccessor}} 
> should leave the millis absolute.
> This manifests as timestamp actual values being shifted by the current locale 
> (in addition to later display adjustments).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CALCITE-4259) Support JDK 15

[Kenneth Knowles (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17198086#comment-17198086
 ] 

Kenneth Knowles commented on CALCITE-4259:
--

I am not very familiar with Calcite's testing setup. Do you have a test matrix 
for a few Java/Guava versions?

> Support JDK 15
> --
>
> Key: CALCITE-4259
> URL: https://issues.apache.org/jira/browse/CALCITE-4259
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.26.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> JDK 15 is now GA (released 2020/09/15). We should support it (and OpenJDK 15) 
> as a build- and run-time platform.
> Also:
> * Upgrade to latest Guava (guava-29.0-jre, released on 2020/04/13);
> * Upgrade log4j2 to latest (2.13.3, release 2020/05/10);
> * Remove log4j (we're on the last release, 1.2.17, which was 2012/05/26, but 
> I assume the project is now unsupported and dead).
> If there are any other important upgrades to be done before 1.26, please add 
> them here.
> Must fix in next release (1.26) or justify why not in this thread.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CALCITE-3339) DESCRIPTOR as a SQL operator in SqlStdOperatorTable

[Kenneth Knowles (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16928276#comment-16928276
 ] 

Kenneth Knowles commented on CALCITE-3339:
--

A `DESCRIPTOR` parameter expression seems only really applicable for opaque 
table functions defined outside SQL. The standard and Oracle lack reasonable 
syntax for using such a value in a SQL query. So a string is not much worse. It 
is less obvious that it is statically type-checkable, but you still can and 
would want to. So you might as well parse the keyword DESCRIPTOR and make it 
obvious it is an identifier with a binding site. That binding site is the 
other, mandatory, table parameter to the function. Notably, the keyword is not 
permissible except as an immediate literal parameter.

> DESCRIPTOR as a SQL operator in SqlStdOperatorTable
> ---
>
> Key: CALCITE-3339
> URL: https://issues.apache.org/jira/browse/CALCITE-3339
> Project: Calcite
>  Issue Type: Sub-task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
>
> For query:
> SELECT * 
> FROM TABLE(TUMBLE_TVF(
> TABLE ORDERS,
> DESCRIPTOR(ROWTIME), 
> INTERVAL '10' MINUTE))
> TABLE ORDERS is converted to SqlPrefixOperator, but DESCRIPTOR(ROWTIME) has 
> no mapping in SqlStdOperatorTable. 
> There are two options:
> 1. There is a SqlColumnListConstructor which serves the same(similar) purpose 
> to specific a list of column. 
> 2. We create a new operator for DESCRIPTOR.
> Reuse existing code is always good so we can start from option one and see if 
> it works.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (CALCITE-3339) DESCRIPTOR as a SQL operator in SqlStdOperatorTable

[Kenneth Knowles (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16928273#comment-16928273
 ] 

Kenneth Knowles commented on CALCITE-3339:
--

Indeed. I pulled it out of the SQL standard at the suggestion of Edmon, who 
knew just where to look to find it. Out there in the world, it appears to exist 
only as COLUMNS in the Oracle dialect 
https://oracle-base.com/articles/18c/polymorphic-table-functions-18c

> DESCRIPTOR as a SQL operator in SqlStdOperatorTable
> ---
>
> Key: CALCITE-3339
> URL: https://issues.apache.org/jira/browse/CALCITE-3339
> Project: Calcite
>  Issue Type: Sub-task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
>
> For query:
> SELECT * 
> FROM TABLE(TUMBLE_TVF(
> TABLE ORDERS,
> DESCRIPTOR(ROWTIME), 
> INTERVAL '10' MINUTE))
> TABLE ORDERS is converted to SqlPrefixOperator, but DESCRIPTOR(ROWTIME) has 
> no mapping in SqlStdOperatorTable. 
> There are two options:
> 1. There is a SqlColumnListConstructor which serves the same(similar) purpose 
> to specific a list of column. 
> 2. We create a new operator for DESCRIPTOR.
> Reuse existing code is always good so we can start from option one and see if 
> it works.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (CALCITE-2394) Avatica applies calendar offset to timestamps when they should remain unchanged

[Kenneth Knowles (Jira)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912895#comment-16912895
 ] 

Kenneth Knowles commented on CALCITE-2394:
--

FWIW here I've recently realized that Beam SQL is probably backwards. We have 
been mapping an absolute Joda-style instant to the Calcite type TIMESTAMP which 
is pretty explicitly wrong. We probably need to decide between `TIMESTAMP WITH 
TIMEZONE` to make it an absolute time (with extraneous metadata) versus 
`TIMESTAMP WITH LOCAL TIMEZONE` which to be honest I don't really understand.

> Avatica applies calendar offset to timestamps when they should remain 
> unchanged
> ---
>
> Key: CALCITE-2394
> URL: https://issues.apache.org/jira/browse/CALCITE-2394
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Kenneth Knowles
>Assignee: Kenneth Knowles
>Priority: Major
>
> This code converts a millis-since-epoch value to a timestamp in three 
> different accessors:
> {code}
> class AbstractCursor {
>   ...
>   static Timestamp longToTimestamp(long v, Calendar calendar) {
> if (calendar != null) {
>   v -= calendar.getTimeZone().getOffset(v);
> }
> return new Timestamp(v);
>   }
> }
> {code}
> But {{new Timestamp(millis)}} always accepts millis-since-epoch in GMT.
> The use in {{DateFromNumberAccessor}} is probably OK: it fabricates 
> millis-since-epoch from a date, so applying the offset is appropriate to hit 
> midnight in that locale.
> But both {{TimeFromNumberAccessor}} and {{TimestampFromNumberAccessor}} 
> should leave the millis absolute.
> This manifests as timestamp actual values being shifted by the current locale 
> (in addition to later display adjustments).



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (CALCITE-2529) linq4j should promote integer to floating point when generating function calls

[Kenneth Knowles (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665836#comment-16665836
 ] 

Kenneth Knowles commented on CALCITE-2529:
--

Since this is already in PR, can we get it in before the release? I added the 
Fix Version field since it does seem to be in use perhaps for tracking this.

> linq4j should promote integer to floating point when generating function calls
> --
>
> Key: CALCITE-2529
> URL: https://issues.apache.org/jira/browse/CALCITE-2529
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Andrew Pilloud
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> For example, I get "RuntimeException: while resolving method 'atan2[double, 
> int]'" when trying to execute a query with "ATAN2(c_double, 2)" (where 
> c_double is a column containing the double type). atan2[double, double] 
> should resolve as a valid implementation in this case.



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

[jira] [Updated] (CALCITE-2529) linq4j should promote integer to floating point when generating function calls

[Kenneth Knowles (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kenneth Knowles updated CALCITE-2529:
-
Fix Version/s: 1.18.0

> linq4j should promote integer to floating point when generating function calls
> --
>
> Key: CALCITE-2529
> URL: https://issues.apache.org/jira/browse/CALCITE-2529
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Andrew Pilloud
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.18.0
>
>
> For example, I get "RuntimeException: while resolving method 'atan2[double, 
> int]'" when trying to execute a query with "ATAN2(c_double, 2)" (where 
> c_double is a column containing the double type). atan2[double, double] 
> should resolve as a valid implementation in this case.



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

[jira] [Comment Edited] (CALCITE-2634) Query parses but fails to convert to rel

[Kenneth Knowles (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16657700#comment-16657700
 ] 

Kenneth Knowles edited comment on CALCITE-2634 at 10/20/18 3:38 AM:


Hmm. Are we invoking this correctly? 
[https://github.com/apache/beam/blob/master/sdks/java/extensions/sql/src/main/java/org/apache/beam/sdk/extensions/sql/impl/BeamQueryPlanner.java#L120]

 

(crash is at 
https://github.com/apache/beam/blob/master/sdks/java/extensions/sql/src/main/java/org/apache/beam/sdk/extensions/sql/impl/BeamQueryPlanner.java#L125)


was (Author: kenn):
Hmm. Are we invoking this correctly? 
https://github.com/apache/beam/blob/master/sdks/java/extensions/sql/src/main/java/org/apache/beam/sdk/extensions/sql/impl/BeamQueryPlanner.java#L120

> Query parses but fails to convert to rel
> 
>
> Key: CALCITE-2634
> URL: https://issues.apache.org/jira/browse/CALCITE-2634
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Kenneth Knowles
>Assignee: Julian Hyde
>Priority: Major
>
> The following query parses but fails to convert to logical rels:
> {code:sql}
> WITH BidCount (auction, num, hopstart) AS (
>   SELECT
> Bid.auction,
> count(*),
> HOP_START(Bid.dateTime, INTERVAL '1' SECOND, INTERVAL '60' SECOND)
>   FROM Bid
>   GROUP BY
> Bid.auction,
> HOP(Bid.dateTime, INTERVAL '1' SECOND, INTERVAL '60' SECOND)
>   )
> SELECT HotAuction.auction, HotAuction.num, HotAuction.hopstart
> FROM BidCount as HotAuction
> WHERE HotAuction.num >= ALL (
>   SELECT num FROM BidCount
>   WHERE HotAuction.hopstart = BidCount.hopstart)
> {code}
> The validated SQL node pretty prints like so:
> {code:sql}
> WITH `BidCount` (`auction`, `num`, `hopstart`) AS (SELECT `Bid`.`auction`, 
> COUNT(*), HOP_START(`Bid`.`dateTime`, INTERVAL '5' SECOND, INTERVAL '10' 
> SECOND)
> FROM `beam`.`Bid` AS `Bid`
> GROUP BY `Bid`.`auction`, HOP(`Bid`.`dateTime`, INTERVAL '5' SECOND, INTERVAL 
> '10' SECOND)) (SELECT `HotAuction`.`auction`, `HotAuction`.`num`, 
> `HotAuction`.`hopstart`
> FROM `BidCount` AS `HotAuction`
> WHERE `HotAuction`.`num` >= ALL (SELECT `BidCount`.`num`
> FROM `BidCount` AS `BidCount`
> WHERE `HotAuction`.`hopstart` = `BidCount`.`hopstart`))
> {code}
> The stack trace is here:
> {code:java}
> java.lang.ClassCastException: org.apache.calcite.rel.logical.LogicalFilter 
> cannot be cast to org.apache.calcite.rel.core.Join
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.translateIn(SqlToRelConverter.java:1242)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.substituteSubQuery(SqlToRelConverter.java:1129)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.replaceSubQueries(SqlToRelConverter.java:997)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:964)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:643)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:621)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3051)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWith(SqlToRelConverter.java:3891)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3065)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
>   at oorg.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:235)
> {code}
> For context, this is working with Beam SQL but the failure occurs before any 
> Beam-related code is reached: [https://github.com/apache/beam/pull/6757/files]
>  



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

[jira] [Commented] (CALCITE-2634) Query parses but fails to convert to rel

[Kenneth Knowles (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16657700#comment-16657700
 ] 

Kenneth Knowles commented on CALCITE-2634:
--

Hmm. Are we invoking this correctly? 
https://github.com/apache/beam/blob/master/sdks/java/extensions/sql/src/main/java/org/apache/beam/sdk/extensions/sql/impl/BeamQueryPlanner.java#L120

> Query parses but fails to convert to rel
> 
>
> Key: CALCITE-2634
> URL: https://issues.apache.org/jira/browse/CALCITE-2634
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Kenneth Knowles
>Assignee: Julian Hyde
>Priority: Major
>
> The following query parses but fails to convert to logical rels:
> {code:sql}
> WITH BidCount (auction, num, hopstart) AS (
>   SELECT
> Bid.auction,
> count(*),
> HOP_START(Bid.dateTime, INTERVAL '1' SECOND, INTERVAL '60' SECOND)
>   FROM Bid
>   GROUP BY
> Bid.auction,
> HOP(Bid.dateTime, INTERVAL '1' SECOND, INTERVAL '60' SECOND)
>   )
> SELECT HotAuction.auction, HotAuction.num, HotAuction.hopstart
> FROM BidCount as HotAuction
> WHERE HotAuction.num >= ALL (
>   SELECT num FROM BidCount
>   WHERE HotAuction.hopstart = BidCount.hopstart)
> {code}
> The validated SQL node pretty prints like so:
> {code:sql}
> WITH `BidCount` (`auction`, `num`, `hopstart`) AS (SELECT `Bid`.`auction`, 
> COUNT(*), HOP_START(`Bid`.`dateTime`, INTERVAL '5' SECOND, INTERVAL '10' 
> SECOND)
> FROM `beam`.`Bid` AS `Bid`
> GROUP BY `Bid`.`auction`, HOP(`Bid`.`dateTime`, INTERVAL '5' SECOND, INTERVAL 
> '10' SECOND)) (SELECT `HotAuction`.`auction`, `HotAuction`.`num`, 
> `HotAuction`.`hopstart`
> FROM `BidCount` AS `HotAuction`
> WHERE `HotAuction`.`num` >= ALL (SELECT `BidCount`.`num`
> FROM `BidCount` AS `BidCount`
> WHERE `HotAuction`.`hopstart` = `BidCount`.`hopstart`))
> {code}
> The stack trace is here:
> {code:java}
> java.lang.ClassCastException: org.apache.calcite.rel.logical.LogicalFilter 
> cannot be cast to org.apache.calcite.rel.core.Join
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.translateIn(SqlToRelConverter.java:1242)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.substituteSubQuery(SqlToRelConverter.java:1129)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.replaceSubQueries(SqlToRelConverter.java:997)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:964)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:643)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:621)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3051)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWith(SqlToRelConverter.java:3891)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3065)
>   at 
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
>   at oorg.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:235)
> {code}
> For context, this is working with Beam SQL but the failure occurs before any 
> Beam-related code is reached: [https://github.com/apache/beam/pull/6757/files]
>  



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

[jira] [Created] (CALCITE-2634) Query parses but fails to convert to rel

[Kenneth Knowles (JIRA)]

Kenneth Knowles created CALCITE-2634:


 Summary: Query parses but fails to convert to rel
 Key: CALCITE-2634
 URL: https://issues.apache.org/jira/browse/CALCITE-2634
 Project: Calcite
  Issue Type: Improvement
Reporter: Kenneth Knowles
Assignee: Julian Hyde


The following query parses but fails to convert to logical rels:
{code:sql}
WITH BidCount (auction, num, hopstart) AS (
  SELECT
Bid.auction,
count(*),
HOP_START(Bid.dateTime, INTERVAL '1' SECOND, INTERVAL '60' SECOND)
  FROM Bid
  GROUP BY
Bid.auction,
HOP(Bid.dateTime, INTERVAL '1' SECOND, INTERVAL '60' SECOND)
  )
SELECT HotAuction.auction, HotAuction.num, HotAuction.hopstart
FROM BidCount as HotAuction
WHERE HotAuction.num >= ALL (
  SELECT num FROM BidCount
  WHERE HotAuction.hopstart = BidCount.hopstart)
{code}

The validated SQL node pretty prints like so:

{code:sql}
WITH `BidCount` (`auction`, `num`, `hopstart`) AS (SELECT `Bid`.`auction`, 
COUNT(*), HOP_START(`Bid`.`dateTime`, INTERVAL '5' SECOND, INTERVAL '10' SECOND)
FROM `beam`.`Bid` AS `Bid`
GROUP BY `Bid`.`auction`, HOP(`Bid`.`dateTime`, INTERVAL '5' SECOND, INTERVAL 
'10' SECOND)) (SELECT `HotAuction`.`auction`, `HotAuction`.`num`, 
`HotAuction`.`hopstart`
FROM `BidCount` AS `HotAuction`
WHERE `HotAuction`.`num` >= ALL (SELECT `BidCount`.`num`
FROM `BidCount` AS `BidCount`
WHERE `HotAuction`.`hopstart` = `BidCount`.`hopstart`))
{code}

The stack trace is here:
{code:java}
java.lang.ClassCastException: org.apache.calcite.rel.logical.LogicalFilter 
cannot be cast to org.apache.calcite.rel.core.Join
at 
org.apache.calcite.sql2rel.SqlToRelConverter.translateIn(SqlToRelConverter.java:1242)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.substituteSubQuery(SqlToRelConverter.java:1129)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.replaceSubQueries(SqlToRelConverter.java:997)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:964)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:643)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:621)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3051)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.convertWith(SqlToRelConverter.java:3891)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3065)
at 
org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:557)
at oorg.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:235)
{code}
For context, this is working with Beam SQL but the failure occurs before any 
Beam-related code is reached: [https://github.com/apache/beam/pull/6757/files]

 



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

[jira] [Comment Edited] (CALCITE-2394) Avatica applies calendar offset to timestamps when they should remain unchanged

[Kenneth Knowles (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530409#comment-16530409
 ] 

Kenneth Knowles edited comment on CALCITE-2394 at 7/2/18 8:30 PM:
--

I believe the calls go like so:

1. ResultSet.getString(col)
2. AvaticaResultSet.getString(col))
3. AvaticaResultSet.getAccessor(col).getString()
4. TimestampAccessor.getString()
5. timestampAsString(TimestampAccessor.getNumber())
6. DateTimeUtils.unixTimestampToString(getNumber() - offset)
7. DateTimeUtils.unixTimestampToString(AvaticaSite.toBigDecimal(col) - offset)

I would describe this as applying timezone translation before converting to 
string. It does not convert to java.sql.Timestamp.

To set up a fuller example for consideration, which I imagine is fairly 
pedestrian: I have a CSV in text or Kafka (etc) with unix timestamps. A user 
imposes a schema on it (CREATE TABLE ... LOCATION ...). They claim that column 
has type TIMESTAMP. Can I make this always have zero offset? My reading of your 
advice is that the user must impose the type TIMESTAMP WITH TIME ZONE and we 
always return a timezone with offset 0. TBH this path has not been on my radar 
so I don't know if it turns out well. It would be much nicer for users if they 
didn't have to type so much and they got a familiar default.


was (Author: kenn):
I believe the calls go like so:

1. ResultSet.getString(col)
2. AvaticaResultSet.getString(col))
3. AvaticaResultSet.getAccessor(col).getString()
4. TimestampAccessor.getString()
5. timestampAsString(TimestampAccessor.getNumber())
6. DateTimeUtils.unixTimestampToString(getNumber() - offset)
7. DateTimeUtils.unixTimestampToString(AvaticaSite.toBigDecimal(col) - offset)

I would describe this as applying timezone translation before converting to 
string. It does not convert to java.sql.Timestamp.

To set up a fuller example for consideration, which I imagine is fairly 
pedestrian: I have a CSV in text or Kafka (etc) with unix timestamps. A user 
imposes a schema on it (CREATE TABLE ... LOCATION ...). They claim that column 
has type TIMESTAMP. Can I make this always have zero offset? My reading of your 
advice is that the user must impose the type TIMESTAMP WITH TIME ZONE and we 
always return a timezone with offset 0. TBH this path has not been on my radar 
so I don't know if it turns out well. It would be much nicer for users if they 
didn't have to type so much.

> Avatica applies calendar offset to timestamps when they should remain 
> unchanged
> ---
>
> Key: CALCITE-2394
> URL: https://issues.apache.org/jira/browse/CALCITE-2394
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Kenneth Knowles
>Assignee: Kenneth Knowles
>Priority: Major
>
> This code converts a millis-since-epoch value to a timestamp in three 
> different accessors:
> {code}
> class AbstractCursor {
>   ...
>   static Timestamp longToTimestamp(long v, Calendar calendar) {
> if (calendar != null) {
>   v -= calendar.getTimeZone().getOffset(v);
> }
> return new Timestamp(v);
>   }
> }
> {code}
> But {{new Timestamp(millis)}} always accepts millis-since-epoch in GMT.
> The use in {{DateFromNumberAccessor}} is probably OK: it fabricates 
> millis-since-epoch from a date, so applying the offset is appropriate to hit 
> midnight in that locale.
> But both {{TimeFromNumberAccessor}} and {{TimestampFromNumberAccessor}} 
> should leave the millis absolute.
> This manifests as timestamp actual values being shifted by the current locale 
> (in addition to later display adjustments).



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

[jira] [Commented] (CALCITE-2394) Avatica applies calendar offset to timestamps when they should remain unchanged

[Kenneth Knowles (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530409#comment-16530409
 ] 

Kenneth Knowles commented on CALCITE-2394:
--

I believe the calls go like so:

1. ResultSet.getString(col)
2. AvaticaResultSet.getString(col))
3. AvaticaResultSet.getAccessor(col).getString()
4. TimestampAccessor.getString()
5. timestampAsString(TimestampAccessor.getNumber())
6. DateTimeUtils.unixTimestampToString(getNumber() - offset)
7. DateTimeUtils.unixTimestampToString(AvaticaSite.toBigDecimal(col) - offset)

I would describe this as applying timezone translation before converting to 
string. It does not convert to java.sql.Timestamp.

To set up a fuller example for consideration, which I imagine is fairly 
pedestrian: I have a CSV in text or Kafka (etc) with unix timestamps. A user 
imposes a schema on it (CREATE TABLE ... LOCATION ...). They claim that column 
has type TIMESTAMP. Can I make this always have zero offset? My reading of your 
advice is that the user must impose the type TIMESTAMP WITH TIME ZONE and we 
always return a timezone with offset 0. TBH this path has not been on my radar 
so I don't know if it turns out well. It would be much nicer for users if they 
didn't have to type so much.

> Avatica applies calendar offset to timestamps when they should remain 
> unchanged
> ---
>
> Key: CALCITE-2394
> URL: https://issues.apache.org/jira/browse/CALCITE-2394
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Kenneth Knowles
>Assignee: Kenneth Knowles
>Priority: Major
>
> This code converts a millis-since-epoch value to a timestamp in three 
> different accessors:
> {code}
> class AbstractCursor {
>   ...
>   static Timestamp longToTimestamp(long v, Calendar calendar) {
> if (calendar != null) {
>   v -= calendar.getTimeZone().getOffset(v);
> }
> return new Timestamp(v);
>   }
> }
> {code}
> But {{new Timestamp(millis)}} always accepts millis-since-epoch in GMT.
> The use in {{DateFromNumberAccessor}} is probably OK: it fabricates 
> millis-since-epoch from a date, so applying the offset is appropriate to hit 
> midnight in that locale.
> But both {{TimeFromNumberAccessor}} and {{TimestampFromNumberAccessor}} 
> should leave the millis absolute.
> This manifests as timestamp actual values being shifted by the current locale 
> (in addition to later display adjustments).



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

[jira] [Commented] (CALCITE-2394) Avatica applies calendar offset to timestamps when they should remain unchanged

[Kenneth Knowles (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530361#comment-16530361
 ] 

Kenneth Knowles commented on CALCITE-2394:
--

Another clarification: my system is using SqlLine + Avatica-based Beam SQL JDBC 
driver so I don't directly control any code calling either method (or at least 
the value proposition of using this toolchain is that I don't have to). What 
you've said makes it sound like it is the responsibility of the JDBC driver to 
choose a timezone for TIMESTAMP values. I would very much like this arbitrary 
choice to always be UTC aka zero offset. Perhaps this is a configuration option 
my entry point to Avatica can set up?

> Avatica applies calendar offset to timestamps when they should remain 
> unchanged
> ---
>
> Key: CALCITE-2394
> URL: https://issues.apache.org/jira/browse/CALCITE-2394
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Kenneth Knowles
>Assignee: Kenneth Knowles
>Priority: Major
>
> This code converts a millis-since-epoch value to a timestamp in three 
> different accessors:
> {code}
> class AbstractCursor {
>   ...
>   static Timestamp longToTimestamp(long v, Calendar calendar) {
> if (calendar != null) {
>   v -= calendar.getTimeZone().getOffset(v);
> }
> return new Timestamp(v);
>   }
> }
> {code}
> But {{new Timestamp(millis)}} always accepts millis-since-epoch in GMT.
> The use in {{DateFromNumberAccessor}} is probably OK: it fabricates 
> millis-since-epoch from a date, so applying the offset is appropriate to hit 
> midnight in that locale.
> But both {{TimeFromNumberAccessor}} and {{TimestampFromNumberAccessor}} 
> should leave the millis absolute.
> This manifests as timestamp actual values being shifted by the current locale 
> (in addition to later display adjustments).



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

[jira] [Comment Edited] (CALCITE-2394) Avatica applies calendar offset to timestamps when they should remain unchanged

[Kenneth Knowles (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530319#comment-16530319
 ] 

Kenneth Knowles edited comment on CALCITE-2394 at 7/2/18 7:10 PM:
--

Not to say that such a thing is without a _shared point of reference_, which is 
essentially universally 1970-01-01 00:00:00Z. But, the pertinent 
characteristics:

 
 # It is _not_ parameterized by any additional data such as a timezone provided 
at retrieval time.
 # No timezone is stored.

It is entirely possible that my experience w/ misc. RDBMSes has left me with a 
gap in understanding of what the SQL standard actually says.


was (Author: kenn):
Not to say that such a thing is without a _shared point of reference_, which is 
essentially universally 1970-01-01 00:00:00Z. But, critically, it is _not_ 
parameterized by any additional data such as a timezone provided at retrieval 
time.

> Avatica applies calendar offset to timestamps when they should remain 
> unchanged
> ---
>
> Key: CALCITE-2394
> URL: https://issues.apache.org/jira/browse/CALCITE-2394
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Kenneth Knowles
>Assignee: Kenneth Knowles
>Priority: Major
>
> This code converts a millis-since-epoch value to a timestamp in three 
> different accessors:
> {code}
> class AbstractCursor {
>   ...
>   static Timestamp longToTimestamp(long v, Calendar calendar) {
> if (calendar != null) {
>   v -= calendar.getTimeZone().getOffset(v);
> }
> return new Timestamp(v);
>   }
> }
> {code}
> But {{new Timestamp(millis)}} always accepts millis-since-epoch in GMT.
> The use in {{DateFromNumberAccessor}} is probably OK: it fabricates 
> millis-since-epoch from a date, so applying the offset is appropriate to hit 
> midnight in that locale.
> But both {{TimeFromNumberAccessor}} and {{TimestampFromNumberAccessor}} 
> should leave the millis absolute.
> This manifests as timestamp actual values being shifted by the current locale 
> (in addition to later display adjustments).



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

[jira] [Comment Edited] (CALCITE-2394) Avatica applies calendar offset to timestamps when they should remain unchanged

[Kenneth Knowles (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530319#comment-16530319
 ] 

Kenneth Knowles edited comment on CALCITE-2394 at 7/2/18 7:10 PM:
--

Not to say that such a thing is without a _shared point of reference_, which is 
essentially universally 1970-01-01 00:00:00Z. But, the pertinent 
characteristics:
 # It is _not_ parameterized by any additional data such as a timezone provided 
at retrieval time.
 # No timezone is stored.

It is entirely possible that my experience w/ misc. RDBMSes has left me with a 
gap in understanding of what the SQL standard actually says.


was (Author: kenn):
Not to say that such a thing is without a _shared point of reference_, which is 
essentially universally 1970-01-01 00:00:00Z. But, the pertinent 
characteristics:

 
 # It is _not_ parameterized by any additional data such as a timezone provided 
at retrieval time.
 # No timezone is stored.

It is entirely possible that my experience w/ misc. RDBMSes has left me with a 
gap in understanding of what the SQL standard actually says.

> Avatica applies calendar offset to timestamps when they should remain 
> unchanged
> ---
>
> Key: CALCITE-2394
> URL: https://issues.apache.org/jira/browse/CALCITE-2394
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Kenneth Knowles
>Assignee: Kenneth Knowles
>Priority: Major
>
> This code converts a millis-since-epoch value to a timestamp in three 
> different accessors:
> {code}
> class AbstractCursor {
>   ...
>   static Timestamp longToTimestamp(long v, Calendar calendar) {
> if (calendar != null) {
>   v -= calendar.getTimeZone().getOffset(v);
> }
> return new Timestamp(v);
>   }
> }
> {code}
> But {{new Timestamp(millis)}} always accepts millis-since-epoch in GMT.
> The use in {{DateFromNumberAccessor}} is probably OK: it fabricates 
> millis-since-epoch from a date, so applying the offset is appropriate to hit 
> midnight in that locale.
> But both {{TimeFromNumberAccessor}} and {{TimestampFromNumberAccessor}} 
> should leave the millis absolute.
> This manifests as timestamp actual values being shifted by the current locale 
> (in addition to later display adjustments).



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

[jira] [Commented] (CALCITE-2394) Avatica applies calendar offset to timestamps when they should remain unchanged

[Kenneth Knowles (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530319#comment-16530319
 ] 

Kenneth Knowles commented on CALCITE-2394:
--

Not to say that such a thing is without a _shared point of reference_, which is 
essentially universally 1970-01-01 00:00:00Z. But, critically, it is _not_ 
parameterized by any additional data such as a timezone provided at retrieval 
time.

> Avatica applies calendar offset to timestamps when they should remain 
> unchanged
> ---
>
> Key: CALCITE-2394
> URL: https://issues.apache.org/jira/browse/CALCITE-2394
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Kenneth Knowles
>Assignee: Kenneth Knowles
>Priority: Major
>
> This code converts a millis-since-epoch value to a timestamp in three 
> different accessors:
> {code}
> class AbstractCursor {
>   ...
>   static Timestamp longToTimestamp(long v, Calendar calendar) {
> if (calendar != null) {
>   v -= calendar.getTimeZone().getOffset(v);
> }
> return new Timestamp(v);
>   }
> }
> {code}
> But {{new Timestamp(millis)}} always accepts millis-since-epoch in GMT.
> The use in {{DateFromNumberAccessor}} is probably OK: it fabricates 
> millis-since-epoch from a date, so applying the offset is appropriate to hit 
> midnight in that locale.
> But both {{TimeFromNumberAccessor}} and {{TimestampFromNumberAccessor}} 
> should leave the millis absolute.
> This manifests as timestamp actual values being shifted by the current locale 
> (in addition to later display adjustments).



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

[jira] [Commented] (CALCITE-2394) Avatica applies calendar offset to timestamps when they should remain unchanged

[Kenneth Knowles (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530293#comment-16530293
 ] 

Kenneth Knowles commented on CALCITE-2394:
--

I think there is a step prior to SQL or JDBC. Ignoring relativity, a moment in 
time has no time zone, platonically.

What I'd like to know, then, is how to correctly store such a thing 
(millisecond precision suffices for now) and retrieve it using Calcite Avatica.

> Avatica applies calendar offset to timestamps when they should remain 
> unchanged
> ---
>
> Key: CALCITE-2394
> URL: https://issues.apache.org/jira/browse/CALCITE-2394
> Project: Calcite
>  Issue Type: Bug
>  Components: avatica
>Reporter: Kenneth Knowles
>Assignee: Kenneth Knowles
>Priority: Major
>
> This code converts a millis-since-epoch value to a timestamp in three 
> different accessors:
> {code}
> class AbstractCursor {
>   ...
>   static Timestamp longToTimestamp(long v, Calendar calendar) {
> if (calendar != null) {
>   v -= calendar.getTimeZone().getOffset(v);
> }
> return new Timestamp(v);
>   }
> }
> {code}
> But {{new Timestamp(millis)}} always accepts millis-since-epoch in GMT.
> The use in {{DateFromNumberAccessor}} is probably OK: it fabricates 
> millis-since-epoch from a date, so applying the offset is appropriate to hit 
> midnight in that locale.
> But both {{TimeFromNumberAccessor}} and {{TimestampFromNumberAccessor}} 
> should leave the millis absolute.
> This manifests as timestamp actual values being shifted by the current locale 
> (in addition to later display adjustments).



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

[jira] [Created] (CALCITE-2394) Avatica applies calendar offset to timestamps when they should remain unchanged

[Kenneth Knowles (JIRA)]

Kenneth Knowles created CALCITE-2394:


 Summary: Avatica applies calendar offset to timestamps when they 
should remain unchanged
 Key: CALCITE-2394
 URL: https://issues.apache.org/jira/browse/CALCITE-2394
 Project: Calcite
  Issue Type: Bug
  Components: avatica
Reporter: Kenneth Knowles
Assignee: Kenneth Knowles


This code converts a millis-since-epoch value to a timestamp in three different 
accessors:

{code}
class AbstractCursor {
  ...
  static Timestamp longToTimestamp(long v, Calendar calendar) {
if (calendar != null) {
  v -= calendar.getTimeZone().getOffset(v);
}
return new Timestamp(v);
  }
}
{code}

But {{new Timestamp(millis)}} always accepts millis-since-epoch in GMT.

The use in {{DateFromNumberAccessor}} is probably OK: it fabricates 
millis-since-epoch from a date, so applying the offset is appropriate to hit 
midnight in that locale.

But both {{TimeFromNumberAccessor}} and {{TimestampFromNumberAccessor}} should 
leave the millis absolute.

This manifests as timestamp actual values being shifted by the current locale 
(in addition to later display adjustments).



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

[jira] [Assigned] (CALCITE-2386) Support columns containing struct / nested rows

[Kenneth Knowles (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kenneth Knowles reassigned CALCITE-2386:


Assignee: Kenneth Knowles

> Support columns containing struct / nested rows
> ---
>
> Key: CALCITE-2386
> URL: https://issues.apache.org/jira/browse/CALCITE-2386
> Project: Calcite
>  Issue Type: Improvement
>  Components: avatica
>Reporter: Kenneth Knowles
>Assignee: Kenneth Knowles
>Priority: Major
>
> Avatica row / struct support appears not quite wired up. Using sqlline with 
> the Beam JDBC driver:
> {code}
> > select row(1, 2);
> ++
> | EXPR$0 |
> ++
> java.lang.RuntimeException: not implemented
>   at 
> org.apache.calcite.avatica.AvaticaSite.notImplemented(AvaticaSite.java:420)
>   at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:302)
>   at 
> org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:377)
>   at sqlline.Rows$Row.(Rows.java:175)
>   at sqlline.IncrementalRows.hasNext(IncrementalRows.java:66)
>   at sqlline.TableOutputFormat.print(TableOutputFormat.java:33)
>   at sqlline.SqlLine.print(SqlLine.java:1648)
>   at sqlline.Commands.execute(Commands.java:834)
>   at sqlline.Commands.sql(Commands.java:733)
>   at sqlline.SqlLine.dispatch(SqlLine.java:795)
>   at sqlline.SqlLine.begin(SqlLine.java:668)
>   at sqlline.SqlLine.start(SqlLine.java:373)
>   at sqlline.SqlLine.main(SqlLine.java:265)
> {code}
> Currently Avatica 1.11.0 but checking the code it looks like the same problem 
> exists today.



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

[jira] [Commented] (CALCITE-2386) Support columns containing struct / nested rows

[Kenneth Knowles (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16525085#comment-16525085
 ] 

Kenneth Knowles commented on CALCITE-2386:
--

https://github.com/apache/calcite-avatica/pull/62

> Support columns containing struct / nested rows
> ---
>
> Key: CALCITE-2386
> URL: https://issues.apache.org/jira/browse/CALCITE-2386
> Project: Calcite
>  Issue Type: Improvement
>  Components: avatica
>Reporter: Kenneth Knowles
>Priority: Major
>
> Avatica row / struct support appears not quite wired up. Using sqlline with 
> the Beam JDBC driver:
> {code}
> > select row(1, 2);
> ++
> | EXPR$0 |
> ++
> java.lang.RuntimeException: not implemented
>   at 
> org.apache.calcite.avatica.AvaticaSite.notImplemented(AvaticaSite.java:420)
>   at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:302)
>   at 
> org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:377)
>   at sqlline.Rows$Row.(Rows.java:175)
>   at sqlline.IncrementalRows.hasNext(IncrementalRows.java:66)
>   at sqlline.TableOutputFormat.print(TableOutputFormat.java:33)
>   at sqlline.SqlLine.print(SqlLine.java:1648)
>   at sqlline.Commands.execute(Commands.java:834)
>   at sqlline.Commands.sql(Commands.java:733)
>   at sqlline.SqlLine.dispatch(SqlLine.java:795)
>   at sqlline.SqlLine.begin(SqlLine.java:668)
>   at sqlline.SqlLine.start(SqlLine.java:373)
>   at sqlline.SqlLine.main(SqlLine.java:265)
> {code}
> Currently Avatica 1.11.0 but checking the code it looks like the same problem 
> exists today.



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

[jira] [Issue Comment Deleted] (CALCITE-2386) Support columns containing struct / nested rows

[Kenneth Knowles (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kenneth Knowles updated CALCITE-2386:
-
Comment: was deleted

(was: https://github.com/apache/calcite-avatica/pull/62)

> Support columns containing struct / nested rows
> ---
>
> Key: CALCITE-2386
> URL: https://issues.apache.org/jira/browse/CALCITE-2386
> Project: Calcite
>  Issue Type: Improvement
>  Components: avatica
>Reporter: Kenneth Knowles
>Priority: Major
>
> Avatica row / struct support appears not quite wired up. Using sqlline with 
> the Beam JDBC driver:
> {code}
> > select row(1, 2);
> ++
> | EXPR$0 |
> ++
> java.lang.RuntimeException: not implemented
>   at 
> org.apache.calcite.avatica.AvaticaSite.notImplemented(AvaticaSite.java:420)
>   at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:302)
>   at 
> org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:377)
>   at sqlline.Rows$Row.(Rows.java:175)
>   at sqlline.IncrementalRows.hasNext(IncrementalRows.java:66)
>   at sqlline.TableOutputFormat.print(TableOutputFormat.java:33)
>   at sqlline.SqlLine.print(SqlLine.java:1648)
>   at sqlline.Commands.execute(Commands.java:834)
>   at sqlline.Commands.sql(Commands.java:733)
>   at sqlline.SqlLine.dispatch(SqlLine.java:795)
>   at sqlline.SqlLine.begin(SqlLine.java:668)
>   at sqlline.SqlLine.start(SqlLine.java:373)
>   at sqlline.SqlLine.main(SqlLine.java:265)
> {code}
> Currently Avatica 1.11.0 but checking the code it looks like the same problem 
> exists today.



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

[jira] [Updated] (CALCITE-2386) Support columns containing struct / nested rows

[Kenneth Knowles (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kenneth Knowles updated CALCITE-2386:
-
Description: 
Avatica row / struct support appears not quite wired up. Using sqlline with the 
Beam JDBC driver:

{code}
> select row(1, 2);
++
| EXPR$0 |
++
java.lang.RuntimeException: not implemented
at 
org.apache.calcite.avatica.AvaticaSite.notImplemented(AvaticaSite.java:420)
at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:302)
at 
org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:377)
at sqlline.Rows$Row.(Rows.java:175)
at sqlline.IncrementalRows.hasNext(IncrementalRows.java:66)
at sqlline.TableOutputFormat.print(TableOutputFormat.java:33)
at sqlline.SqlLine.print(SqlLine.java:1648)
at sqlline.Commands.execute(Commands.java:834)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
{code}

Currently Avatica 1.11.0 but checking the code it looks like the same problem 
exists today.

  was:
Avatica row / struct support appears not quite wired up. Using sqlline with the 
Beam JDBC driver:

{code}
select row(1, 2);
++
| EXPR$0 |
++
java.lang.RuntimeException: not implemented
at 
org.apache.calcite.avatica.AvaticaSite.notImplemented(AvaticaSite.java:420)
at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:302)
at 
org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:377)
at sqlline.Rows$Row.(Rows.java:175)
at sqlline.IncrementalRows.hasNext(IncrementalRows.java:66)
at sqlline.TableOutputFormat.print(TableOutputFormat.java:33)
at sqlline.SqlLine.print(SqlLine.java:1648)
at sqlline.Commands.execute(Commands.java:834)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
{code}

Currently Avatica 1.11.0 but checking the code it looks like the same problem 
exists today.


> Support columns containing struct / nested rows
> ---
>
> Key: CALCITE-2386
> URL: https://issues.apache.org/jira/browse/CALCITE-2386
> Project: Calcite
>  Issue Type: Improvement
>  Components: avatica
>Reporter: Kenneth Knowles
>Priority: Major
>
> Avatica row / struct support appears not quite wired up. Using sqlline with 
> the Beam JDBC driver:
> {code}
> > select row(1, 2);
> ++
> | EXPR$0 |
> ++
> java.lang.RuntimeException: not implemented
>   at 
> org.apache.calcite.avatica.AvaticaSite.notImplemented(AvaticaSite.java:420)
>   at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:302)
>   at 
> org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:377)
>   at sqlline.Rows$Row.(Rows.java:175)
>   at sqlline.IncrementalRows.hasNext(IncrementalRows.java:66)
>   at sqlline.TableOutputFormat.print(TableOutputFormat.java:33)
>   at sqlline.SqlLine.print(SqlLine.java:1648)
>   at sqlline.Commands.execute(Commands.java:834)
>   at sqlline.Commands.sql(Commands.java:733)
>   at sqlline.SqlLine.dispatch(SqlLine.java:795)
>   at sqlline.SqlLine.begin(SqlLine.java:668)
>   at sqlline.SqlLine.start(SqlLine.java:373)
>   at sqlline.SqlLine.main(SqlLine.java:265)
> {code}
> Currently Avatica 1.11.0 but checking the code it looks like the same problem 
> exists today.



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

[jira] [Created] (CALCITE-2386) Support columns containing struct / nested rows

[Kenneth Knowles (JIRA)]

Kenneth Knowles created CALCITE-2386:


 Summary: Support columns containing struct / nested rows
 Key: CALCITE-2386
 URL: https://issues.apache.org/jira/browse/CALCITE-2386
 Project: Calcite
  Issue Type: Improvement
  Components: avatica
Reporter: Kenneth Knowles


Avatica row / struct support appears not quite wired up. Using sqlline with the 
Beam JDBC driver:

{code}
select row(1, 2);
++
| EXPR$0 |
++
java.lang.RuntimeException: not implemented
at 
org.apache.calcite.avatica.AvaticaSite.notImplemented(AvaticaSite.java:420)
at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:302)
at 
org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:377)
at sqlline.Rows$Row.(Rows.java:175)
at sqlline.IncrementalRows.hasNext(IncrementalRows.java:66)
at sqlline.TableOutputFormat.print(TableOutputFormat.java:33)
at sqlline.SqlLine.print(SqlLine.java:1648)
at sqlline.Commands.execute(Commands.java:834)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
{code}

Currently Avatica 1.11.0 but checking the code it looks like the same problem 
exists today.



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