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

Julian Hyde commented on CALCITE-2782:
--------------------------------------

I agree with [~jcamachorodriguez]'s suggestion. (Actually 
{{TimeZone.getDefault().getName()}}, since the value is a string.)

In the javadoc, tighten up what is meant by 'default'. Make it clear that the 
ConnectionConfig.timeZone() method never returns null, and that it returns the 
name of the server's time zone if "timeZone" is not specified in the connect 
string.

> EXTRACT function doesn't work because of NULL returned from 
> druidQuery.getConnectionConfig().timeZone()
> -------------------------------------------------------------------------------------------------------
>
>                 Key: CALCITE-2782
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2782
>             Project: Calcite
>          Issue Type: Bug
>          Components: druid
>    Affects Versions: 1.18.0
>            Reporter: Justin Szeluga
>            Assignee: Julian Hyde
>            Priority: Major
>
> The default value for BuiltInConnectionProperty.TIME_ZONE is null. If the 
> timezone is not set in the properties then the null is returned and a 
> NullPointerException is thrown when PeriodGranularity initializes.
> {code:java}
> Caused by: java.lang.RuntimeException: Error while applying rule 
> DruidProjectRule, args 
> [rel#303:LogicalProject.NONE.[](input=RelSubset#145,EXPR$0=EXTRACT(FLAG(DAY), 
> $0)), rel#213:DruidQuery.BINDABLE.[](table=[adhoc, 
> bach.sign_ctrl_f],intervals=[2019-01-08T00:00:00.000Z/3000-01-01T00:00:00.000Z])]
>     at 
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:236)
>     at 
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:641)
>     at org.apache.calcite.tools.Programs.lambda$standard$3(Programs.java:298)
>     at 
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:358)
>     at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:189)
>     at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:320)
>     at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
>     at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:772)
>     at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:636)
>     at 
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:606)
>     at 
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:229)
>     at 
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
>     at 
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
>     at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
>     ... 14 more
> Caused by: java.lang.NullPointerException
>     at java.util.Objects.requireNonNull(Unknown Source)
>     at 
> org.apache.calcite.adapter.druid.Granularities$PeriodGranularity.<init>(Granularities.java:93)
>     at 
> org.apache.calcite.adapter.druid.Granularities$PeriodGranularity.<init>(Granularities.java:85)
>     at 
> org.apache.calcite.adapter.druid.Granularities.createGranularity(Granularities.java:57)
>     at 
> org.apache.calcite.adapter.druid.DruidDateTimeUtils.extractGranularity(DruidDateTimeUtils.java:331)
>     at 
> org.apache.calcite.adapter.druid.DruidQuery.toDruidColumn(DruidQuery.java:273)
>     at 
> org.apache.calcite.adapter.druid.DruidQuery.computeProjectAsScan(DruidQuery.java:763)
>     at 
> org.apache.calcite.adapter.druid.DruidRules$DruidProjectRule.onMatch(DruidRules.java:298)
>     at 
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
>     ... 27 more
> {code}
> In tests, org.apache.calcite.test.CalciteAssert#assertQuery sets the timezone 
> to UTC hiding the problem. When I issue queries from DBeaver it fails because 
> of the NPE



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

Reply via email to