[jira] [Created] (CALCITE-4641) SqlParser parse single sql statement ending with a semicolon throws exception

2021-06-07 Thread Zhengqiang Duan (Jira) 
Zhengqiang Duan created CALCITE-4641:


 Summary: SqlParser parse single sql statement ending with a 
semicolon throws exception
 Key: CALCITE-4641
 URL: https://issues.apache.org/jira/browse/CALCITE-4641
 Project: Calcite
  Issue Type: Improvement
  Components: core
Reporter: Zhengqiang Duan


Currently, when parsing a single SQL statement ending with a semicolon, like 
`select * from dual;`, the following exception will be thrown.

 

 
{code:java}
org.apache.calcite.sql.parser.SqlParseException: Encountered ";" at line 1, 
column 19.Was expecting one of:         "AS" ...    "EXCEPT" ...    
"EXTEND" ...    "FETCH" ...    "FOR" ...    "GROUP" ...    "HAVING" ...    
"INTERSECT" ...    "LIMIT" ...    "MATCH_RECOGNIZE" ...    "OFFSET" ...    
"ORDER" ...    "MINUS" ...    "TABLESAMPLE" ...    "UNION" ...    "WHERE" ...   
 "WINDOW" ...    "(" ...     ...    
 ...     ...    
 ...     ...     
...    "/*+" ...    "NATURAL" ...    "JOIN" ...    "INNER" ...    "LEFT" ...    
"RIGHT" ...    "FULL" ...    "CROSS" ...    "," ...    "OUTER" ...    "." ...   
 java.lang.RuntimeException: org.apache.calcite.sql.parser.SqlParseException: 
Encountered ";" at line 1, column 19.Was expecting one of:         "AS" 
...    "EXCEPT" ...    "EXTEND" ...    "FETCH" ...    "FOR" ...    "GROUP" ...  
  "HAVING" ...    "INTERSECT" ...    "LIMIT" ...    "MATCH_RECOGNIZE" ...    
"OFFSET" ...    "ORDER" ...    "MINUS" ...    "TABLESAMPLE" ...    "UNION" ...  
  "WHERE" ...    "WINDOW" ...    "(" ...     ...    
 ...     ...    
 ...     ...     
...    "/*+" ...    "NATURAL" ...    "JOIN" ...    "INNER" ...    "LEFT" ...    
"RIGHT" ...    "FULL" ...    "CROSS" ...    "," ...    "OUTER" ...    "." ...   
  at 
org.apache.calcite.sql.parser.SqlParseException.writeReplace(SqlParseException.java:171)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498) at 
java.io.ObjectStreamClass.invokeWriteReplace(ObjectStreamClass.java:1118) at 
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1136) at 
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348) at 
org.gradle.internal.serialize.Message.send(Message.java:36) at 
org.gradle.internal.serialize.BaseSerializerFactory$ThrowableSerializer.write(BaseSerializerFactory.java:321)
 at 
org.gradle.internal.serialize.BaseSerializerFactory$ThrowableSerializer.write(BaseSerializerFactory.java:313)
 at 
org.gradle.internal.remote.internal.hub.DefaultMethodArgsSerializer$ArraySerializer.write(DefaultMethodArgsSerializer.java:80)
 at 
org.gradle.internal.remote.internal.hub.DefaultMethodArgsSerializer$ArraySerializer.write(DefaultMethodArgsSerializer.java:61)
 at 
org.gradle.internal.remote.internal.hub.MethodInvocationSerializer$MethodInvocationWriter.writeArgs(MethodInvocationSerializer.java:78)
 at 
org.gradle.internal.remote.internal.hub.MethodInvocationSerializer$MethodInvocationWriter.write(MethodInvocationSerializer.java:74)
 at 
org.gradle.internal.remote.internal.hub.MethodInvocationSerializer$MethodInvocationWriter.write(MethodInvocationSerializer.java:58)
 at 
org.gradle.internal.serialize.kryo.TypeSafeSerializer$2.write(TypeSafeSerializer.java:47)
 at 
org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageWriter.write(InterHubMessageSerializer.java:104)
 at 
org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageWriter.write(InterHubMessageSerializer.java:88)
 at 
org.gradle.internal.remote.internal.inet.SocketConnection.dispatch(SocketConnection.java:122)
 at 
org.gradle.internal.remote.internal.hub.MessageHub$ConnectionDispatch.run(MessageHub.java:328)
 at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
 at 
org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at 
org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
 at java.lang.Thread.run(Thread.java:748)
{code}
I think the sql statement contains a semicolon result, which is a legal 
grammar, and I hope it can be supported. Thanks!

 



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

Git review activity statistics

2021-06-07 Thread Stamatis Zampetakis 
Hi all,

As requested, in another thread I outline below some stats from the Calcite
repo (didn't include numbers from the Avatica repo) around reviews. The
numbers report only merges of non-committer commits; these are more
important since they help to keep the community alive and allows us to
invite new members.

The rate that we are reviewing and merging PRs has significantly decreased
and this certainly related to the number of active reviewers. Apart from
the few people (Julian, Danny, Haisheng, Chunwei) that are already helping
a lot, the rest of us should try to do better.

Contributor (non-committer) commits per month
+-+-+-+
|year |month| contributor_commits |
+-+-+-+
| 2020| 1   | 22  |
| 2020| 2   | 9   |
| 2020| 3   | 12  |
| 2020| 4   | 22  |
| 2020| 5   | 19  |
| 2020| 6   | 18  |
| 2020| 7   | 17  |
| 2020| 8   | 3   |
| 2020| 9   | 18  |
| 2020| 10  | 13  |
| 2020| 11  | 16  |
| 2020| 12  | 6   |
| 2021| 1   | 6   |
| 2021| 2   | 9   |
| 2021| 3   | 8   |
| 2021| 4   | 14  |
| 2021| 5   | 4   |
+-+-+-+

Active reviewers per month
+-+-+-+
|year |month|  active_reviewers   |
+-+-+-+
| 2020| 1   | 8   |
| 2020| 2   | 7   |
| 2020| 3   | 7   |
| 2020| 4   | 9   |
| 2020| 5   | 7   |
| 2020| 6   | 8   |
| 2020| 7   | 6   |
| 2020| 8   | 3   |
| 2020| 9   | 8   |
| 2020| 10  | 7   |
| 2020| 11  | 6   |
| 2020| 12  | 3   |
| 2021| 1   | 2   |
| 2021| 2   | 5   |
| 2021| 3   | 6   |
| 2021| 4   | 3   |
| 2021| 5   | 4   |
+-+-+-+

Reviews per committer since 2020-01-01 till now
+---+-+
| committer |   reviews   |
+---+-+
| Julian Hyde  | 35  |
| yuzhao.cyz  | 34  |
| Haisheng Yuan  | 31  |
| chunwei <37774589+chunwei...@users.noreply.github.com> | 21
   |
| Stamatis Zampetakis  | 18  |
| rubenada  | 14  |
| Haisheng Yuan <15352793+hsy...@users.noreply.github.com> | 13
 |
| Wang Yanlin <1989yanlinw...@163.com> | 8   |
| Feng Zhu  | 6   |
| Chunwei Lei  | 5   |
| Michael Mior  | 4   |
| Rui Wang  | 4   |
| Vladimir Sitnikov  | 4   |
| amaliujia  | 3   |
| Rui Wang  | 3   |
| Michael Mior  | 2   |
| ForwardXu  | 2   |
| chenyuzhao  | 2   |
| Laurent Goujon  | 2
|
| liyafan82  | 2   |
| Jin Xing  | 1   |
| Zoltan Haindrich  | 1   |
| Danny Chan  | 1   |
+---+-+

Best,
Stamatis

Re: Possibly incorrect assertion in the TopDownRuleDriver.DeriveTrait.derive

2021-06-07 Thread Haisheng Yuan 
> Shouldn't we remove the assertion above?
Perhaps.

Or perhaps the rel2Subset mapping is not up to date.

Regards,
Haisheng Yuan

On 2021/06/06 13:09:16, Vladimir Ozerov  wrote: 
> Hi,
> 
> When doing a trait derivation in the non-OMAKASE mode, the following lines
> of code are invoked:
> 1: RelSubset relSubset = planner.register(newRel, rel);
> 2: assert relSubset.set == planner.getSubset(rel).set;
> 
> The assertion on the second line may fail because the "newRel" is assigned
> not the "rel" set, but "rel" *canonical set*, which might be different.
> 
> As a workaround, we may change the derive mode to OMAKASE. In this case, we
> do not hit the assertion and planning completes successfully.
> 
> Shouldn't we remove the assertion above?
> 
> Regards,
> Vladimir.
>

[jira] [Created] (CALCITE-4640) Propagate table scan hints to JDBC

2021-06-07 Thread Ulrich Kramer (Jira) 
Ulrich Kramer created CALCITE-4640:
--

 Summary: Propagate table scan hints to JDBC
 Key: CALCITE-4640
 URL: https://issues.apache.org/jira/browse/CALCITE-4640
 Project: Calcite
  Issue Type: Improvement
  Components: core
Affects Versions: 1.27.0
Reporter: Ulrich Kramer
 Fix For: next


We would like to use table scan hints to pass [parameters and variables to HANA 
views|https://help.sap.com/viewer/88fe5f56472e40cca6ef3c3dcab4855b/2.0.04/en-US/fafb3ea432e54fca9eff11648df5bccd.html].

It should be possible to convert the following Calcite SQL
{code}
SELECT * FROM VIEW /*+ PLACEHOLDERS("$$PARAMETER_1$$"='Test') */
{code}
using a special {{SqlDialect}} to a HANA specific statement
{code}
SELECT * FROM VIEW ('PLACEHOLDER' = ('$$PARAMETER_1$$', 'Test'))
{code}
See also my [mail in the mailing 
list|https://mail-archives.apache.org/mod_mbox/calcite-dev/202105.mbox/%3CD161B82F-5DEC-49A2-A873-4817F4DEB15F%40contoso.com%3E].



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