[jira] [Commented] (CALCITE-1074) Please delete old releases from mirroring system

[Sebb (JIRA)]

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

Sebb commented on CALCITE-1074:
---

Thanks.

Please can you ensure that the release guide (if any) mentions the need to 
remove old releases?

Since the announce message should only be sent when most of the mirrors have 
picked up the new release, that is a good time for the RM to drop any old 
release(s).

> Please delete old releases from mirroring system
> 
>
> Key: CALCITE-1074
> URL: https://issues.apache.org/jira/browse/CALCITE-1074
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.5.0
> Environment: https://dist.apache.org/repos/dist/release/calcite/
>Reporter: Sebb
>Assignee: Julian Hyde
> Fix For: 1.7.0
>
>
> To reduce the load on the ASF mirrors, projects are required to delete old 
> releases [1]
> Please can you remove all non-current releases?
> i.e. 1.5.0
> Thanks!
> [1] http://www.apache.org/dev/release.html#when-to-archive



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CALCITE-998) Query with stddev fails with internal error

[Julian Hyde (JIRA)]

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

Julian Hyde resolved CALCITE-998.
-
   Resolution: Fixed
Fix Version/s: 1.7.0

Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/7ce2e621. Thanks 
for the PR, [~msh...@gmail.com]!

> Query with stddev fails with internal error
> ---
>
> Key: CALCITE-998
> URL: https://issues.apache.org/jira/browse/CALCITE-998
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.5.0
>Reporter: Sudheesh Katkam
>Assignee: Julian Hyde
> Fix For: 1.7.0
>
>
> Two incomplete but failing unit tests. 
> {code}
>   @Test public void testStddevSampOnKnownType() throws Exception {
> CalciteAssert.that()
> .with(CalciteAssert.Config.FOODMART_CLONE)
> .query("SELECT STDDEV_SAMP(CAST(\"store_id\" AS INT)) AS col FROM 
> \"store\"")
> .returns("");
>   }
>   @Test public void testStddevPopOnKnownType() throws Exception {
> CalciteAssert.that()
> .with(CalciteAssert.Config.FOODMART_CLONE)
> .query("SELECT STDDEV_POP(CAST(\"store_id\" AS INT)) AS col FROM 
> \"store\"")
> .returns("");
>   }
> {code}
> Stack trace:
> {code}
> java.lang.AssertionError: Internal error: Error while applying rule 
> AggregateReduceFunctionsRule, args 
> [rel#11:LogicalAggregate.NONE.[](input=rel#10:Subset#2.NONE.[0],group={},COL=STDDEV_SAMP($0))]
>   at org.apache.calcite.util.Util.newInternal(Util.java:792)
>   at 
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:251)
>   at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:827)
>   at org.apache.calcite.tools.Programs$5.run(Programs.java:273)
>   at 
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:321)
>   at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:145)
>   at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:282)
>   at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:190)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:728)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:587)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:557)
>   at 
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214)
>   at 
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:573)
>   at 
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571)
>   at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135)
>   at 
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:186)
>   at 
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:469)
>   at 
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1202)
>   at 
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1185)
>   at 
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1149)
>   at 
> org.apache.calcite.test.JdbcTest.testStddevOnKnownType(JdbcTest.java:2885)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 

[jira] [Updated] (CALCITE-998) Exception when calling STDDEV_SAMP, STDDEV_POP

[Julian Hyde (JIRA)]

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

Julian Hyde updated CALCITE-998:

Summary: Exception when calling STDDEV_SAMP, STDDEV_POP  (was: Query with 
stddev fails with internal error)

> Exception when calling STDDEV_SAMP, STDDEV_POP
> --
>
> Key: CALCITE-998
> URL: https://issues.apache.org/jira/browse/CALCITE-998
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.5.0
>Reporter: Sudheesh Katkam
>Assignee: Julian Hyde
> Fix For: 1.7.0
>
>
> Two incomplete but failing unit tests. 
> {code}
>   @Test public void testStddevSampOnKnownType() throws Exception {
> CalciteAssert.that()
> .with(CalciteAssert.Config.FOODMART_CLONE)
> .query("SELECT STDDEV_SAMP(CAST(\"store_id\" AS INT)) AS col FROM 
> \"store\"")
> .returns("");
>   }
>   @Test public void testStddevPopOnKnownType() throws Exception {
> CalciteAssert.that()
> .with(CalciteAssert.Config.FOODMART_CLONE)
> .query("SELECT STDDEV_POP(CAST(\"store_id\" AS INT)) AS col FROM 
> \"store\"")
> .returns("");
>   }
> {code}
> Stack trace:
> {code}
> java.lang.AssertionError: Internal error: Error while applying rule 
> AggregateReduceFunctionsRule, args 
> [rel#11:LogicalAggregate.NONE.[](input=rel#10:Subset#2.NONE.[0],group={},COL=STDDEV_SAMP($0))]
>   at org.apache.calcite.util.Util.newInternal(Util.java:792)
>   at 
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:251)
>   at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:827)
>   at org.apache.calcite.tools.Programs$5.run(Programs.java:273)
>   at 
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:321)
>   at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:145)
>   at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:282)
>   at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:190)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:728)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:587)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:557)
>   at 
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214)
>   at 
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:573)
>   at 
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571)
>   at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135)
>   at 
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:186)
>   at 
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:469)
>   at 
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1202)
>   at 
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1185)
>   at 
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1149)
>   at 
> org.apache.calcite.test.JdbcTest.testStddevOnKnownType(JdbcTest.java:2885)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
>   at 
> 

[jira] [Comment Edited] (CALCITE-998) Exception when calling STDDEV_SAMP, STDDEV_POP

[Julian Hyde (JIRA)]

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

Julian Hyde edited comment on CALCITE-998 at 2/4/16 12:01 AM:
--

Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/7ce2e621. Thanks 
for the PR, [~msh...@gmail.com]!

I refactored your pull request a bit. I didn't want complicated stuff going on 
inside AggregateCall.create, so I pulled the type-derivation outside. But you 
were spot-on as to the root cause - operand ordinals being in terms of a 
RelNode that had not yet been created. I also added a couple of tests, and 
enabled some old ones that had never been enabled before.


was (Author: julianhyde):
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/7ce2e621. Thanks 
for the PR, [~msh...@gmail.com]!

> Exception when calling STDDEV_SAMP, STDDEV_POP
> --
>
> Key: CALCITE-998
> URL: https://issues.apache.org/jira/browse/CALCITE-998
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.5.0
>Reporter: Sudheesh Katkam
>Assignee: Julian Hyde
> Fix For: 1.7.0
>
>
> Two incomplete but failing unit tests. 
> {code}
>   @Test public void testStddevSampOnKnownType() throws Exception {
> CalciteAssert.that()
> .with(CalciteAssert.Config.FOODMART_CLONE)
> .query("SELECT STDDEV_SAMP(CAST(\"store_id\" AS INT)) AS col FROM 
> \"store\"")
> .returns("");
>   }
>   @Test public void testStddevPopOnKnownType() throws Exception {
> CalciteAssert.that()
> .with(CalciteAssert.Config.FOODMART_CLONE)
> .query("SELECT STDDEV_POP(CAST(\"store_id\" AS INT)) AS col FROM 
> \"store\"")
> .returns("");
>   }
> {code}
> Stack trace:
> {code}
> java.lang.AssertionError: Internal error: Error while applying rule 
> AggregateReduceFunctionsRule, args 
> [rel#11:LogicalAggregate.NONE.[](input=rel#10:Subset#2.NONE.[0],group={},COL=STDDEV_SAMP($0))]
>   at org.apache.calcite.util.Util.newInternal(Util.java:792)
>   at 
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:251)
>   at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:827)
>   at org.apache.calcite.tools.Programs$5.run(Programs.java:273)
>   at 
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:321)
>   at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:145)
>   at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:282)
>   at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:190)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:728)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:587)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:557)
>   at 
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214)
>   at 
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:573)
>   at 
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571)
>   at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135)
>   at 
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:186)
>   at 
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:469)
>   at 
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1202)
>   at 
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1185)
>   at 
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1149)
>   at 
> org.apache.calcite.test.JdbcTest.testStddevOnKnownType(JdbcTest.java:2885)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> 

[jira] [Commented] (CALCITE-1072) CSV adapter incorrectly parses TIMESTAMP values after noon

[Chris Albright (JIRA)]

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

Chris Albright commented on CALCITE-1072:
-

No worries  I'm glad you were able to fix it with just the bug report.



> CSV adapter incorrectly parses TIMESTAMP values after noon
> --
>
> Key: CALCITE-1072
> URL: https://issues.apache.org/jira/browse/CALCITE-1072
> Project: Calcite
>  Issue Type: Bug
>Reporter: Chris Albright
>Assignee: Julian Hyde
> Fix For: 1.7.0
>
>
> When querying timestamp data using the CSV adapter, the time is always in A.M.
> for example this input file: EXAMPLE_DATA.csv
> ID:long,START:timestamp,END:timestamp
> 1,"2015-12-31 07:15:56","2015-12-31 13:31:21"
> yields this output in sqlline:
> select * from example_data;
> | ID | START | END |
> | 1  | 2015-12-31 07:15:56 | 2015-12-31 01:31:21 |
> The bug appears to be in org.apache.calcite.adapter.csv.CsvEnumerator on 
> lines 59 and 60. The parse formats use 'hh' instead of 'HH' for the hour part.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CALCITE-604) Invoke metadata providers via a class generated at runtime, rather than reflection

[Vladimir Sitnikov (JIRA)]

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

Vladimir Sitnikov commented on CALCITE-604:
---

I'll pick it up this Sunday.

> Invoke metadata providers via a class generated at runtime, rather than 
> reflection
> --
>
> Key: CALCITE-604
> URL: https://issues.apache.org/jira/browse/CALCITE-604
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> JDK 1.7 introduced 
> http://docs.oracle.com/javase/7/docs/api/java/lang/invoke/MethodHandle.html, 
> a more efficient way to invoke methods. Access control etc. is done when the 
> handle is created, not each invocation.
> Currently calls to metadata providers are dispatched via reflection 
> (Method.invoke, see ReflectiveRelMetadataProvider, ChainedRelMetadataProvider 
> and CachingInvocationHandler), and I suspect that planning a complex query 
> (especially with tracing enabled) makes millions of calls. Reflection has a 
> performance problem; lots of boxing and unboxing and creating temporary 
> arrays and bound objects.
> One option we considered to improve performance was moving to MethodHandle. 
> However, MethodHandle.invoke can dispatch only within one provider.
> So, we should generate a handler class, and compile and instantiate at run 
> time using Janino.
> For each metadata interface we will need to add a handler interface that has 
> the same methods but two extra arguments (a sub-class of RelNode, and a 
> RelMetadataQuery). Previously these arguments were passed by calling "bind" 
> on an UnboundMetadata.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CALCITE-604) Invoke metadata providers via a class generated at runtime, rather than reflection

[Jacques Nadeau (JIRA)]

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

Jacques Nadeau commented on CALCITE-604:


I just haven't been able to get to this, sorry. Don't wait for me.

> Invoke metadata providers via a class generated at runtime, rather than 
> reflection
> --
>
> Key: CALCITE-604
> URL: https://issues.apache.org/jira/browse/CALCITE-604
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> JDK 1.7 introduced 
> http://docs.oracle.com/javase/7/docs/api/java/lang/invoke/MethodHandle.html, 
> a more efficient way to invoke methods. Access control etc. is done when the 
> handle is created, not each invocation.
> Currently calls to metadata providers are dispatched via reflection 
> (Method.invoke, see ReflectiveRelMetadataProvider, ChainedRelMetadataProvider 
> and CachingInvocationHandler), and I suspect that planning a complex query 
> (especially with tracing enabled) makes millions of calls. Reflection has a 
> performance problem; lots of boxing and unboxing and creating temporary 
> arrays and bound objects.
> One option we considered to improve performance was moving to MethodHandle. 
> However, MethodHandle.invoke can dispatch only within one provider.
> So, we should generate a handler class, and compile and instantiate at run 
> time using Janino.
> For each metadata interface we will need to add a handler interface that has 
> the same methods but two extra arguments (a sub-class of RelNode, and a 
> RelMetadataQuery). Previously these arguments were passed by calling "bind" 
> on an UnboundMetadata.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CALCITE-1072) CSV adapter incorrectly parses TIMESTAMP values after noon

[Julian Hyde (JIRA)]

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

Julian Hyde commented on CALCITE-1072:
--

[~ChrisAlbright], I only just noticed your pull request, 
https://github.com/apache/calcite/pull/190. Sorry I didn't see it - I would 
have liked the git commit record to give you credit for tracking this down and 
fixing it. I can't change the git commit record now, but I'll give you credit 
in the release notes.

> CSV adapter incorrectly parses TIMESTAMP values after noon
> --
>
> Key: CALCITE-1072
> URL: https://issues.apache.org/jira/browse/CALCITE-1072
> Project: Calcite
>  Issue Type: Bug
>Reporter: Chris Albright
>Assignee: Julian Hyde
> Fix For: 1.7.0
>
>
> When querying timestamp data using the CSV adapter, the time is always in A.M.
> for example this input file: EXAMPLE_DATA.csv
> ID:long,START:timestamp,END:timestamp
> 1,"2015-12-31 07:15:56","2015-12-31 13:31:21"
> yields this output in sqlline:
> select * from example_data;
> | ID | START | END |
> | 1  | 2015-12-31 07:15:56 | 2015-12-31 01:31:21 |
> The bug appears to be in org.apache.calcite.adapter.csv.CsvEnumerator on 
> lines 59 and 60. The parse formats use 'hh' instead of 'HH' for the hour part.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CALCITE-1076) Metadata distribution is broken due to last refactor

[Ted Xu (JIRA)]

Ted Xu created CALCITE-1076:
---

 Summary: Metadata distribution is broken due to last refactor
 Key: CALCITE-1076
 URL: https://issues.apache.org/jira/browse/CALCITE-1076
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.7.0
Reporter: Ted Xu
Assignee: Julian Hyde


Metadata distribution is broken due to last refactor.

Calls of RelMdDistribution will get:

{code}
java.lang.AssertionError: are your methods named wrong?
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CALCITE-642) Avatica server metrics

[Julian Hyde (JIRA)]

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

Julian Hyde commented on CALCITE-642:
-

OK, full regress + javadoc succeeded on JDK 1.7 and 1.8 for change f9ccaa6.

> Avatica server metrics
> --
>
> Key: CALCITE-642
> URL: https://issues.apache.org/jira/browse/CALCITE-642
> Project: Calcite
>  Issue Type: Improvement
>  Components: avatica
>Reporter: Nick Dimiduk
>Assignee: Josh Elser
>  Labels: avatica
> Fix For: next
>
>
> Along the same lines as CALCITE-641, avatica server should track some basic 
> metrics. We can expose them through a "standard" API (such as Hadoop metrics, 
> or Dropwizard metrics), and include them on some interval in the service log.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CALCITE-1076) Metadata distribution is broken due to last refactor

[Julian Hyde (JIRA)]

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

Julian Hyde commented on CALCITE-1076:
--

If you've created your own metadata provider you will need to add an extra 
{{RelMetadataQuery mq}} argument to each method, per CALCITE-794. This was 
mentioned in the release notes, 
http://calcite.apache.org/docs/history.html#v1-6-0.

> Metadata distribution is broken due to last refactor
> 
>
> Key: CALCITE-1076
> URL: https://issues.apache.org/jira/browse/CALCITE-1076
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.7.0
>Reporter: Ted Xu
>Assignee: Julian Hyde
>
> Metadata distribution is broken due to last refactor.
> Calls of RelMdDistribution will get:
> {code}
> java.lang.AssertionError: are your methods named wrong?
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CALCITE-1076) Metadata distribution is broken due to last refactor

[Ted Xu (JIRA)]

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

Ted Xu commented on CALCITE-1076:
-

I created a pull request at https://github.com/apache/calcite/pull/193.
Julian please kindly review it.

> Metadata distribution is broken due to last refactor
> 
>
> Key: CALCITE-1076
> URL: https://issues.apache.org/jira/browse/CALCITE-1076
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.7.0
>Reporter: Ted Xu
>Assignee: Julian Hyde
>
> Metadata distribution is broken due to last refactor.
> Calls of RelMdDistribution will get:
> {code}
> java.lang.AssertionError: are your methods named wrong?
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CALCITE-1076) Metadata distribution is broken due to last refactor

[Julian Hyde (JIRA)]

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

Julian Hyde commented on CALCITE-1076:
--

Ah, I see now. The other way of way of stating this bug is: RelMdDistribution 
is not tested. If there were a test, the assert would have shown up. Do you 
feel like adding a test to RelMetadataTest? (I don't think the test in your 
patch exercises the metadata provider, so it won't exercise this bug.)

> Metadata distribution is broken due to last refactor
> 
>
> Key: CALCITE-1076
> URL: https://issues.apache.org/jira/browse/CALCITE-1076
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.7.0
>Reporter: Ted Xu
>Assignee: Julian Hyde
>
> Metadata distribution is broken due to last refactor.
> Calls of RelMdDistribution will get:
> {code}
> java.lang.AssertionError: are your methods named wrong?
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CALCITE-1074) Please delete old releases from mirroring system

[Julian Hyde (JIRA)]

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

Julian Hyde commented on CALCITE-1074:
--

We already have documented a policy to drop the last-but-one. 

> Please delete old releases from mirroring system
> 
>
> Key: CALCITE-1074
> URL: https://issues.apache.org/jira/browse/CALCITE-1074
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.5.0
> Environment: https://dist.apache.org/repos/dist/release/calcite/
>Reporter: Sebb
>Assignee: Julian Hyde
> Fix For: 1.7.0
>
>
> To reduce the load on the ASF mirrors, projects are required to delete old 
> releases [1]
> Please can you remove all non-current releases?
> i.e. 1.5.0
> Thanks!
> [1] http://www.apache.org/dev/release.html#when-to-archive



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CALCITE-1075) UDF Error of Calcite 1.6

[Julian Hyde (JIRA)]

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

Julian Hyde commented on CALCITE-1075:
--

This might be related to CALCITE-1054, but it's not possible to check without a 
test case. Can you provide a patch with a test case?

> UDF Error of Calcite 1.6 
> -
>
> Key: CALCITE-1075
> URL: https://issues.apache.org/jira/browse/CALCITE-1075
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.6.0
>Reporter: Wei Hu
>Assignee: Julian Hyde
>
> UDF Error In Calcite 1.6, may be Regression bugs?
> schema：Table:hr,  A String， B String， C String， D Timestamp
> UDF： DATE_TRUNC（Timestamp D, String X） returns a timestamp value
> there a several regression bugs. 1.5 is ok, but 1.6 will throw exception:
> 1. UDF in Group_by clause,
> sql：select  min(m0), max(m0)  from (select DATE_TRUNC(D, 'month') as d1, 
> COUNT(A) as m0 from \"hr\" group by DATE_TRUNC(D, 'month'))
> Error Stack：
> Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to 
> java.lang.Long
>   at Baz$2.apply(Unknown Source)
>   at Baz$2.apply(Unknown Source)
>   at 
> org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:821)
>   at 
> org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:754)
>   at 
> org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302)
>   at Baz.bind(Unknown Source)
>   at 
> org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:326)
>   at 
> org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:281)
>   at 
> org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:545)
>   at 
> org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:536)
>   at 
> org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:187)
>   at 
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:65)
>   at 
> org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44)
>   at 
> org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:566)
>   at 
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:578)
>   at 
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571)
>   at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135)
>   ... 2 more
>   
>   
> 2. select UDF
> sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D
> throw exception when call  resultSet.getTimestamp(1)
> Error stack: 
> Exception in thread "main" java.lang.ClassCastException: java.sql.Timestamp 
> cannot be cast to java.lang.Number
>   at 
> org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:696)
>   at 
> org.apache.calcite.avatica.util.AbstractCursor$TimestampFromNumberAccessor.getTimestamp(AbstractCursor.java:958)
>   at 
> org.apache.calcite.avatica.AvaticaResultSet.getTimestamp(AvaticaResultSet.java:285)
>   at testPs.TestPs.main(TestPs.java:150)
>   
> 3. UDFs with same name and different arg types
> UDF： DATE_TRUNC（Timestamp D, String x） returns a timestamp value
> DATE_TRUNC(Date D, String x) returns a date value
> 
> sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D
> Error stack：
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1, 
> column 11 to line 1, column 32: Cannot apply 'DATE_TRUNC' to arguments of 
> type 'DATE_TRUNC(, )'. Supported form(s): 
> 'DATE_TRUNC(, )'
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>   at 
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:405)
>   at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:715)
>   at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:703)
>   at 
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:3932)
>   at 
> org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:275)
>   at 
> org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkSingleOperandType(FamilyOperandTypeChecker.java:92)
>   at 
> 

[jira] [Commented] (CALCITE-998) Query with stddev fails with internal error

[Matthew Shaer (JIRA)]

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

Matthew Shaer commented on CALCITE-998:
---

It does now :)

> Query with stddev fails with internal error
> ---
>
> Key: CALCITE-998
> URL: https://issues.apache.org/jira/browse/CALCITE-998
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.5.0
>Reporter: Sudheesh Katkam
>Assignee: Julian Hyde
>
> Two incomplete but failing unit tests. 
> {code}
>   @Test public void testStddevSampOnKnownType() throws Exception {
> CalciteAssert.that()
> .with(CalciteAssert.Config.FOODMART_CLONE)
> .query("SELECT STDDEV_SAMP(CAST(\"store_id\" AS INT)) AS col FROM 
> \"store\"")
> .returns("");
>   }
>   @Test public void testStddevPopOnKnownType() throws Exception {
> CalciteAssert.that()
> .with(CalciteAssert.Config.FOODMART_CLONE)
> .query("SELECT STDDEV_POP(CAST(\"store_id\" AS INT)) AS col FROM 
> \"store\"")
> .returns("");
>   }
> {code}
> Stack trace:
> {code}
> java.lang.AssertionError: Internal error: Error while applying rule 
> AggregateReduceFunctionsRule, args 
> [rel#11:LogicalAggregate.NONE.[](input=rel#10:Subset#2.NONE.[0],group={},COL=STDDEV_SAMP($0))]
>   at org.apache.calcite.util.Util.newInternal(Util.java:792)
>   at 
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:251)
>   at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:827)
>   at org.apache.calcite.tools.Programs$5.run(Programs.java:273)
>   at 
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:321)
>   at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:145)
>   at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:282)
>   at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:190)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:728)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:587)
>   at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:557)
>   at 
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:214)
>   at 
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:573)
>   at 
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571)
>   at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135)
>   at 
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:186)
>   at 
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:469)
>   at 
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1202)
>   at 
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1185)
>   at 
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1149)
>   at 
> org.apache.calcite.test.JdbcTest.testStddevOnKnownType(JdbcTest.java:2885)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
>   at 
> 

[jira] [Commented] (CALCITE-1062) Allowing SqlOperator to be overridden in validation

[Julian Hyde (JIRA)]

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

Julian Hyde commented on CALCITE-1062:
--

* I no longer think it needs to be in SqlOperatorTable. But I think you should 
unify lookupSqlOperator with lookupRoutine. Generalize lookupRoutine to handle 
SqlOperator, rather than copy-pasting. You could add a type parameter "" if you like.
* Would it be possible to move SqlFunction.deriveType up to SqlOperator? The 
methods are essentially doing the same thing.
* Use StringBuilder not StringBuffer. In fact for that particular case, just 
use +
* Use plural name for collections: rename operatorType to operatorTypes.
* Remove the 'toUpperCase' hack. The core is case-sensitive.
* Any reason your test cannot be in the base class SqlOperatorBaseTest? It 
should be obvious that test cases shouldn't be defined in 
CalciteSqlOperatorTest.
* Use assertThat, not assertEquals

> Allowing SqlOperator to be overridden in validation
> ---
>
> Key: CALCITE-1062
> URL: https://issues.apache.org/jira/browse/CALCITE-1062
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Reporter: Sean Hsuan-Yi Chu
>Assignee: Sean Hsuan-Yi Chu
>
> Calcite allows function to be overridden at validation step. To be more 
> specific, users can provide their SqlOperatorTable, and, at validation step, 
> their SqlOperatorTable will be called (method: lookupOperatorOverloads) to 
> get a overriding function.  However, so far, SqlOperator (e.g., +, - , *, 
> etc.) does not have this mechanism yet. 
> Since other systems (e.g., Apache Drill) would have more flexible type-checks 
> for SqlOperator's operands, this mechanism is necessary for those systems to 
> pass through the validation step.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)