Mutual TLS support

[Soman Ullah]

Hello,
Does Avatica support mutual TLS? If so, could someone please provide
relevant documentation on how to set it up?

Thanks,
Somanesh

Re: SqlValidator: given a scope, how to resolve a column name?

[Julian Hyde]

If you have hit EmptyScope, that probably means that the validator has tried 
other scopes and found nothing. Usually (e.g. inside a SELECT clause) the 
validator uses a ListScope, with the tables in the FROM clause making up the 
list of namespaces in which to search for columns. Each scope has a parent that 
it delegates to if it finds nothing, and EmptyScope is the end of the line.

Julian


> On Nov 21, 2019, at 3:37 PM, Rui Wang  wrote:
> 
> Hi community,
> 
> 
> SqlValidatorScope defines RelDataType resolveColumn(String name, SqlNode ctx
> ) to help resolve a column name in scope and return its type. However, in
> the implementation that is used during validation phase, which is
> EmptyScope, the implementation returns null directly (see [2]).
> 
> Is it intentional to return null for the implementation of EmptyScope? Is
> there an alternative way to achieve what resolveColumn is designed for, or
> I have to implement that in EmptyScope to be able to use it?
> 
> 
> 
> [1]:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorScope.java#L161
> 
> [2]:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/EmptyScope.java#L189
> 
> -Rui

SqlValidator: given a scope, how to resolve a column name?

[Rui Wang]

Hi community,


SqlValidatorScope defines RelDataType resolveColumn(String name, SqlNode ctx
) to help resolve a column name in scope and return its type. However, in
the implementation that is used during validation phase, which is
EmptyScope, the implementation returns null directly (see [2]).

Is it intentional to return null for the implementation of EmptyScope? Is
there an alternative way to achieve what resolveColumn is designed for, or
I have to implement that in EmptyScope to be able to use it?



[1]:
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorScope.java#L161

[2]:
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/EmptyScope.java#L189

-Rui

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Xiening Dai]

In case you didn’t know, JetBrains offers a free subscription to all Apache 
committers.

https://blog.jetbrains.com/blog/2019/05/30/jetbrains-supports-the-apache-software-foundation/
 



> On Nov 21, 2019, at 1:51 PM, Haisheng Yuan  wrote:
> 
> Thanks, Danny. Will try with newer version.
> 
> - Haisheng
> 
> --
> 发件人：Danny Chan
> 日　期：2019年11月21日 10:50:12
> 收件人：
> 主　题：Re: Re: CALCITE-2905: Maven -> Gradle: any thoughts
> 
> Haisheng, upgrade to IDEA 2019.3 EAP solves the problem for me.
> 
> Best,
> Danny Chan
> 在 2019年11月21日 +0800 AM9:24，Haisheng Yuan ，写道：
>> Hi Vladimir,
>> 
>> I had the same error:
>> Unable to load class 'org.gradle.api.internal.plugins.DefaultConvention'.
>> 
>> IntelliJ IDEA 2018.3.4 (Community Edition)
>> Build #IC-183.5429.30, built on January 28, 2019
>> JRE: 1.8.0_152-release-1343-b26 x86_64
>> JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
>> macOS 10.14.4
>> 
>> - Haisheng
>> 
>> --
>> 发件人：Danny Chan
>> 日　期：2019年11月20日 17:31:18
>> 收件人：
>> 主　题：Re: CALCITE-2905: Maven -> Gradle: any thoughts
>> 
>> When I use the IDEA 2019.9 version, it works ~
>> 
>> But the travis test is failing for the slow test: here is my log 
>> https://travis-ci.org/apache/calcite/jobs/614406384?utm_medium=notification_source=github_status
>> 
>> Best,
>> Danny Chan
>> 在 2019年11月20日 +0800 PM2:28，Vladimir Sitnikov 
>> ，写道：
 Here is the stacktrace:
>>> java.lang.NoClassDefFoundError: org/gradle/api/internal/plugin
>>> s/DefaultConvention
>>> at org.jetbrains.plugins.gradle.tooling.builder.ProjectExtensio
>>> nsDataBuilderImpl.buildAll(ProjectExtensionsDataBuilderImpl.groovy:50)
>>> 
>>> What is IDEA version?
>>> 
>>> Vladimir
>> 
> 

Re: Re: Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Haisheng Yuan]

Thanks, Danny. Will try with newer version.

- Haisheng

--
发件人：Danny Chan
日　期：2019年11月21日 10:50:12
收件人：
主　题：Re: Re: CALCITE-2905: Maven -> Gradle: any thoughts

Haisheng, upgrade to IDEA 2019.3 EAP solves the problem for me.

Best,
Danny Chan
在 2019年11月21日 +0800 AM9:24，Haisheng Yuan ，写道：
> Hi Vladimir,
>
> I had the same error:
> Unable to load class 'org.gradle.api.internal.plugins.DefaultConvention'.
>
> IntelliJ IDEA 2018.3.4 (Community Edition)
> Build #IC-183.5429.30, built on January 28, 2019
> JRE: 1.8.0_152-release-1343-b26 x86_64
> JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
> macOS 10.14.4
>
> - Haisheng
>
> --
> 发件人：Danny Chan
> 日　期：2019年11月20日 17:31:18
> 收件人：
> 主　题：Re: CALCITE-2905: Maven -> Gradle: any thoughts
>
> When I use the IDEA 2019.9 version, it works ~
>
> But the travis test is failing for the slow test: here is my log 
> https://travis-ci.org/apache/calcite/jobs/614406384?utm_medium=notification_source=github_status
>
> Best,
> Danny Chan
> 在 2019年11月20日 +0800 PM2:28，Vladimir Sitnikov ，写道：
> > > Here is the stacktrace:
> > java.lang.NoClassDefFoundError: org/gradle/api/internal/plugin
> > s/DefaultConvention
> > at org.jetbrains.plugins.gradle.tooling.builder.ProjectExtensio
> > nsDataBuilderImpl.buildAll(ProjectExtensionsDataBuilderImpl.groovy:50)
> >
> > What is IDEA version?
> >
> > Vladimir
>

[DISCUSS] New Apache Calcite Chair

[Francis Chuang]

Hey everyone,

It's Calcite's tradition to rotate the chair every year. When we had the 
State of the Project discussion [1] a month ago, there was some 
consensus towards nominating Stamatis Zampetakis as our next chair.


Stamatis has been a prolific contributor to the project and I believe he 
would be a very good choice to chair the project in the coming year.


Please let us know your thoughts!

Francis

[1] 
https://lists.apache.org/thread.html/e85dbc88546687571c5dd9fd999a19d0eae52004c3b3e5b92c67d9bb@%3Cdev.calcite.apache.org%3E

Re: Progress on adding TUMBLE as table value function (CALCITE-3272)

[Rui Wang]

I didn't find such discussion in the SQL standard (maybe I have missed
something).

My current thought is not to convert "rowtime" to upper-case is the best:
1. for those not column name case-sensitive database, it works.
2. for those case-sensitive database, assume users are aware of their
sources that are case-sensitive, I think their intention to use descriptor
will consider that factor. Converting column names to upper-case causes
confusion.


-Rui



On Wed, Nov 20, 2019 at 6:55 PM Julian Hyde  wrote:

> If I write
>
>  DESCRIPTOR(rowtime)
>
> and I am running Calcite’s parser in a mode that converts unquoted
> identifiers to upper-case, do you think that it should convert “rowtime” to
> upper-case?
>
> I am undecided. It’s possible that “rowtime” references a column in a
> case-sensitive database.
>
> Julian
>
>
> > On Nov 20, 2019, at 11:14 AM, Rui Wang  wrote:
> >
> > Forgot to mention, the DESCRIPTOR support means the following query will
> be
> > able to run:
> >
> > SELECT *
> > FROM TABLE(Tumble(
> >  TABLE ORDERS ,
> >  DESCRIPTOR(ROWTIME) ,
> > INTERVAL '1' MINUTES))
> >
> >
> > Note that the second parameter to indicate the watermarked column is
> > changed from a string(varchar) to DESCRIPTOR(col_name).
> >
> >
> > -Rui
> >
> >
> > On Wed, Nov 20, 2019 at 11:04 AM Rui Wang  wrote:
> >
> >> I have an update:
> >>
> >> I tried to add DESCRIPTOR support (CALCITE-3339). Amazingly it was not
> >> complicated at all to have a working version. So I created #1599[1],
> which
> >> is built on top of #1587[2], to demonstrate DESCRIPTOR. The PRs are
> >> separated because DESCRIPTOR support currently is less mature.
> >>
> >>
> >> [1]: https://github.com/apache/calcite/pull/1599
> >> [2]: https://github.com/apache/calcite/pull/1587
> >>
> >>
> >> -Rui
> >>
> >> On Thu, Nov 14, 2019 at 9:35 PM Rui Wang  wrote:
> >>
> >>> Hi community,
> >>>
> >>> I have created a new PR ( https://github.com/apache/calcite/pull/1587)
> >>> to demonstrate the progress of TUMBLE table value function
> (CALCITE-3272).
> >>> Julian suggested me to have a working version that adds a stream.iq
> and
> >>> have an enumerable implementation. Those are in the PR.
> >>>
> >>> High level speaking, the PR is adding a support of the following:
> >>>
> >>> SELECT *
> >>> FROM TABLE(Tumble(
> >>>  TABLE ORDERS ,
> >>>  'ROWTIME' ,
> >>> INTERVAL '1' MINUTES))
> >>>
> >>>
> >>> One missing feature so far is adding support of DESCRIPTOR, which is
> >>> intentionally cut off from the PR because that will make the PR more
> >>> complicated. Thus DESCRIPTOR is left as future work.
> >>>
> >>> The PR solves not only CALCITE-3272, but also it's blockers:
> >>> https://jira.apache.org/jira/browse/CALCITE-3340
> >>> https://jira.apache.org/jira/browse/CALCITE-3501
> >>> https://jira.apache.org/jira/browse/CALCITE-3499
> >>> https://jira.apache.org/jira/browse/CALCITE-3418
> >>>
> >>>
> >>> I will probably need some guidance on how to proceed to get the PR
> >>> merged. Please let me know if you have any thoughts.
> >>>
> >>> -Rui
> >>>
> >>
>
>

[jira] [Created] (CALCITE-3529) TIMESTAMPDIFF function may overflow when handle unit of MICROSECOND/NANOSECOND

[Zhenghua Gao (Jira)]

Zhenghua Gao created CALCITE-3529:
-

 Summary: TIMESTAMPDIFF function may overflow when handle unit of 
MICROSECOND/NANOSECOND
 Key: CALCITE-3529
 URL: https://issues.apache.org/jira/browse/CALCITE-3529
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.21.0
Reporter: Zhenghua Gao


For unit of NANOSECOND, the TIMESTAMPDIFF function returns a BIGINT, which may 
overflow since BIGINT can't cover the huge range of nanosecond. 

For unit of MICROSECOND, the TIMESTAMPDIFF function returns a INTEGER, which 
may overflow too.

TIMESTAMPDIFF(MICROSECOND, TIMESTAMP '-12-31 23:59:59.999', TIMESTAMP 
'0001-01-01 00:00:00.000') should returns '31553789759000' [1], calcite 
returns '879764032'. 

 

TIMESTAMPDIFF(NANOSECOND, TIMESTAMP '-12-31 23:59:59.999', TIMESTAMP 
'0001-01-01 00:00:00.000') should returns '31553789759000*000*' which is 
bigger than LONG.MAX_VALUE, calcite returns '-1943248345937622528'.

 

My suggestion is:
 # Change the return type to BIGINT for unit of MICROSECOND
 # Disable support for unit of NANOSECOND or give a RISK message in the 
document of TIMESTAMPDIFF

[1] the value is calculated by MySQL 5.6 from [http://sqlfiddle.com/]



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

[jira] [Created] (CALCITE-3528) TIMESTAMPADD/TIMESTAMPDIFF can't handle unit of MILLISECOND

[Zhenghua Gao (Jira)]

Zhenghua Gao created CALCITE-3528:
-

 Summary: TIMESTAMPADD/TIMESTAMPDIFF can't handle unit of 
MILLISECOND
 Key: CALCITE-3528
 URL: https://issues.apache.org/jira/browse/CALCITE-3528
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.21.0
Reporter: Zhenghua Gao


Calcite's SQL parser can't handle unit of MILLISECOND for 
TIMESTAMPADD/TIMESTAMPDIFF functions. And I checked MySql[1], which can't 
handle unit of MILLISECOND too. 

Is there any reason to not support unit of MILLISECOND of the two function?

 [1] 
[https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_timestampadd]



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